From 71cd333baaa0e9638fb4c8274d8259ca742ee5f6 Mon Sep 17 00:00:00 2001 From: Marc Gravell Date: Fri, 4 Nov 2016 12:32:26 +0000 Subject: [PATCH] Fix #634 - dapper now handles connection lifetime and has for ages --- Readme.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Readme.md b/Readme.md index c38a0253f..c99a3beca 100644 --- a/Readme.md +++ b/Readme.md @@ -344,9 +344,7 @@ Limitations and caveats --------------------- Dapper caches information about every query it runs, this allow it to materialize objects quickly and process parameters quickly. The current implementation caches this information in a ConcurrentDictionary object. The objects it stores are never flushed. If you are generating SQL strings on the fly without using parameters it is possible you will hit memory issues. We may convert the dictionaries to an LRU Cache. -Dapper's simplicity means that many feature that ORMs ship with are stripped out, there is no identity map, there are no helpers for update / select and so on. - -Dapper does not manage your connection's lifecycle, it assumes the connection it gets is open AND has no existing datareaders enumerating (unless MARS is enabled) +Dapper's simplicity means that many feature that ORMs ship with are stripped out. It worries about the 95% scenario, and gives you the tools you need most of the time. It doesn't attempt to solve every problem. Will Dapper work with my DB provider? ---------------------