retire these bindings in favor of rusqlite?

[dckc]

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

[PeterReid]

In my use of these bindings, I prepare a bunch of statements when my application starts up and then execute them many times as it runs. This mean I have a struct that goes like:

struct DatabaseApi {
    conn: DatabaseConnection,
    select_whatever: PreparedStatement,
    select_something_else: PrepareStatement,
    insert_thing: PreparedStatement,
}

This is what motivated commit 934d784 on this library -- before, with statements having a lifetime parameter that made them have to outlive conn, that would not compile. In rusqlite, they still have that lifetime parameter. I wonder if they have figured out a pattern which accomplishes what I was trying to do, or if users of it just always prepare statements just in time.

[theduke]

Hey, I created this thread before finding this issue.

But maybe you can join the discussion there: https://users.rust-lang.org/t/sqlite-libraries-potential-for-unification/8702

@dckc

[jgallagher]

To address the two points above about things that were missing in rusqlite:

• Connection::handle gives you access to the raw SQLite connection
• Connection::prepare_cached does still return statements with a lifetime, but they will be returned to a Connection-local cache when they're dropped, and calling prepare_cached again with the same SQL statement will return that cached statement without round-tripping through SQLite again.

[dckc]

What's The Right Thing To Do with https://crates.io/crates/rust-sqlite ?