Life gets much better if I change this to:

pub fn exec(&self, sql: &str) -> SqliteResult<()>

The consistency-based argument here is that exec() and prepare() should be the same.

The not-very-compelling argument is that exec(&mut self) means that I can only call exec() from one reference and that's a huge pain.

But I'll admit that whenever I think about the boundary between "safety assurances provided by SQLite" and "additional safety assurances provided by Rust", I get myself tied up in knots.

Now that rusqlite has addressed the lifetime issues with query_map(), there's not much reason to maintain these bindings.

I'm inclined to give this project a once-over and raise issues there for anything that's novel here.

I made a note about the expose() method on one of their issues... it's a closed issue, though, so maybe I should look into that some more.

cc @jgallagher @PeterReid @dgilman @AndiDog @ericsink

Hello,

I have troubles cargo building your library (using nightly Rust and Cargo from 2014-10-14):

/Users/olda/Code/rust/rust-sqlite3/src/types.rs:111:25: 111:81 error: mismatched types: expected `&str`, found `&[collections::string::String]` (expected str, found unsized array)
/Users/olda/Code/rust/rust-sqlite3/src/types.rs:111         s.bind_text(ix, time::at_utc(*self).strftime(SQLITE_TIME_FMT).as_slice())

I tried fixing it, but failed. :-) I understand that &str is the same as &[u8] (http://doc.rust-lang.org/std/str/index.html#representation) but when I did this, It complained that &[u8] isn't &str.:

impl ToSql for time::Timespec {
    fn to_sql(&self, s: &mut PreparedStatement, ix: uint) -> SqliteResult<()> {
        let time_string = time::at_utc(*self).strftime(SQLITE_TIME_FMT).unwrap();
        let time_str    = time_string.as_bytes();
        s.bind_text(ix, time_str)
    }
}

I'm curious what the fix is.

Thanks, Ollie

Was always incorrect, and from Rust 1.9 or so, Cargo will actually warn about it (will become an error at some point).

It must either be

[dependencies.time]
version = "^0.1.5"

or just plain below "[dependencies]":

[dependencies]
time = "^0.1.5"

In fbf297b, I stopped using sqlite_close_v2 for compatibility with sqlite 3.7.9, provided by Ubuntu 12.04, used by travis. #11 is a pull request to get sqlite3_errstr via SQLite3 3.7.15.1.

I'd like to use this issue to consider the options.

You'll need to add a commit to change a few things on top of this:

• add your encrypted Github access token to ./.travis.yml again (I followed the Giving Travis Permissions section here http://www.hoverbear.org/2015/03/07/rust-travis-github-pages/ )
• change documentation link in Cargo.toml to your github pages URL
• change docs and Build Status url/badge in README.md to your github/travis URLs

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.

FromSql and column_text/blob/str/slice unnecessarily required rows to be mutable. This prevented having references to two slices from the same row as once.

Add zero-copy column getters and fix potential non-UTF8 Strings

Sqlite3's notion of text corresponds more closely to Rust's notion of [u8]s than strs in two important ways:

• Sqlite3's text, like [u8]s and unlike strs, can contain non-UTF8 sequences.
• Sqlite3's text, unlike strs, must be null-terminated.

This makes sqlite3_column_blob work at least as well as sqlite3_column_text for getting a str into Rust. Never using sqlite3_column_text has another advantage: mixing calls to sqlite3_column_blob and sqlite3_column_text may cause the underlying buffer to be reallocated, invalidating the old buffer. By only ever calling the _blob variant, the buffer returned will be valid for as long as the row. This makes it possible to safely expose zero-copy column getters for &[u8] and &str.

And I added myself to the authors list.

Previously, PreparedStatement did not actually use its 'db lifetime, so the lifetime checks behaved as if there was no bound on the lifetime. A rustc change made that a compile error. Adding a PhantomData there, and so making the lifetime have to be respected, make a number of other changes necessary. There are now separate lifetime parameters for statements, result sets, and rows. Not having separate lifetime parameters would cut off, (for example) a PreparedStatement's lifetime when it got executed, even after the ResultSet that came from that execute went out of scope. I believe that was because the lifetimes got somehow fused together when the ResultSet was made.

A second change is that prepare() takes a reference instead of a mutable reference. The compiler was treating the PreparedStatement that came from the prepare as if it kept ownership of the DatabaseConnection without that. It seems like there ought to be a way around this, but I didn't find it.

The open_file_db test didn't work on Windows, where there is not usually a /tmp directory. The rustc changes were: Show has changed to Display and io is now old_io.

The documentation on rust-ci.org (linked to from the README) seems to have fallen out of date.

For example, http://www.rust-ci.org/dckc/rust-sqlite3/doc/sqlite3/trait.DatabaseUpdate.html seems to have been removed from the source (in a good way), and http://www.rust-ci.org/dckc/rust-sqlite3/doc/sqlite3/access/fn.open.html is documented as taking one argument but actually takes two.

This does seem like a nice API to Sqlite3, but I'm getting thrown off a bit by the outdated documentation. I'll switch to locally-generated docs for now.