On the relationship between ResultSet and PreparedStatement

[ericsink]

I've worked myself into an unhappy spot.

Basically, I'm building an API which wants to return a set of rows. The API is not sqlite-specific, but this implementation of it is.

Normally I would just return a struct that wraps the sqlite3_stmt. Something like this:

struct MyRows {
    stmt: PreparedStatement,
}

Currently I am trying to code against the core layer of rust-sqlite3. So in order to return a struct that contains what I need, it has to look kinda like this:

struct MyRows {
    stmt: PreparedStatement,
    rset: ResultSet,
}

But ResultSet is a reference to a PreparedStatement, so Rust isn't going to allow this. (Google for things talking about a struct which contains both data and a reference to it.)

Basically, right now I wish that ResultSet owned its PreparedStatement instead of having a reference to same. Then I would just do this:

struct MyRows {
    rset: ResultSet,
}

But I also realize that if it were designed this way, I would very likely be wishing for the other approach, since I would want the ability to reuse the statement handle after the current result set has been processed.

I think maybe I wish that ResultSet didn't exist at all, which means I would end up with an API more similar to the sqlite3 API to which I am accustomed. But I haven't worked through the implications of that here in Rust land.

I could get around this by coding against the ffi layer instead. And I might end up doing that. But for now I wanted to raise this issue about the design of the core layer.

[dckc]

This is now Somebody Else's Problem :)
See #46