-
Notifications
You must be signed in to change notification settings - Fork 80
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
Arrow's lifetime is tied to connection's lifetime #208
Comments
The Arrow object here is an Iterator that you can call That's what we need to as if you close |
I see. I guess that's where the difference between Arrow's arrow and Duckdb's arrow starts. I wonder if there's a pattern to keep the current behavior and also extend the arrow's life cycle without the need to copy anything |
We shouldn’t copy, we should move |
When a
Statement
is prepared from within aConnection
by callingconn.prepare(...)
, the method takes itsInnerConnection
field (db
) and callsInnerConnection::prepare
by passing a reference to itself. If success, the new generated statement will have a lifetime that can live at most the same amount asconn: Connection
(which was passed as a reference to InnerConnection).We can query the
duckdb::arrow_batch::Arrow
data by callingStatement::query_arrow
, which does its wizardry to fetch the data and generate a newArrow
struct. It does that by giving it its own ownership. In other terms, Arrow will live at most the same amount thatconn Connection
.I'm not sure if I understood correctly, but you can only have an duckdb::arrow_batch::Arrow object as long as the
conn Connection
is alive. Is that intentional?The text was updated successfully, but these errors were encountered: