Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<ol> <li>your code doesn't show where you open/close the connection; but the <em>reader</em> here will actually only be open <em>while you are iterating the data</em>. Deferred execution, etc. The only bit of your code that does this is the <code>.ToList()</code>, so it'll be fine. In the more general case, yes: the reader will be open for the amount of time you take to iterate it; if you do a <code>.ToList()</code> that will be minimal; if you do a <code>foreach</code> and (for every item) make an external http request and wait 20 seconds, then yes - it will be open for longer.</li> <li>Both have their uses; the non-buffered approach is great for huge results that you want to process as a stream, without ever having to load them into a single in-memory list (or even have all of them in memory at a time); returning a list keeps the connection closed quickly, and makes it easy to avoid accidentally using the connection while it already has an open reader, but is not ideal for large results</li> </ol> <p>If you return an iterator block, the caller can decide what is sane; if you always return a list, they don't have much option. A third way (that we do in dapper) is to make the choice theirs; we have an optional <code>bool</code> parameter which defaults to "return a list", but which the caller can change to indicate "return an iterator block"; basically:</p> <pre><code>bool buffered = true </code></pre> <p>in the parameters, and:</p> <pre><code>var data = QueryInternal&lt;T&gt;(...blah...); return buffered ? data.ToList() : data; </code></pre> <p>in the implementation. In most cases, returning a list is perfectly reasonable and avoids a lot of problems, hence we make that the default.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload