-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ToObjectStream #92
Comments
See also #281 |
|
This won't implement |
This is going to need new Data Source methods. Namely ExecuteStream and ExecuteStreamAsync. These methods will create a connection, but never close it. The result object will have to handle closing itself via Dispose/DisposeAsync. |
For a open or transactional data source, the Dispose call will be a no-op. |
Before we implement this, we should document the full pipeline for a normal Execute call. |
We're going to need the pre-existing |
Previously, Chain would fully manage database connections by default. Specifically, it would open and close connections automatically unless a transaction was involved. In that case, the developer only needed to manage the transactional data source itself. However, there are times when a result set is too large to handle at one time. In this case the developer will want an When used in place of This object stream may be used directly, as shown below, or attached to an RX Observable or TPL Dataflow just like any other enumerable data structure. //sync pattern
using var objectStream = dataSource.From<Employee>(new { Title = uniqueKey }).ToObjectStream<Employee>().Execute();
foreach (var item in objectStream)
{
Assert.AreEqual(uniqueKey, item.Title);
}
//async pattern
await using var objectStream = await dataSource.From<Employee>(new { Title = uniqueKey }).ToObjectStream<Employee>().ExecuteAsync();
await foreach (var item in objectStream)
{
Assert.AreEqual(uniqueKey, item.Title);
} It is vital that the object stream is disposed after use. If that doesn't occur, the database can suffer from thread exhaustion or deadlocks. |
When working with really large result sets, it may be preferable to stream the data instead of materializing a list.
Both NPoco and Dapper already support this:
To do better we need to marry it with something that still manages lifecycles. For example, the exposed enumerator needs to close the connection.
Maybe include Reactive Extensions support with this.
The text was updated successfully, but these errors were encountered: