Remove libc crate dependency by upgrading libsqlite3-sys

[jgallagher]

This is followup from jgallagher/rusqlite#237 and #715.

I haven't really looked into what it would entail, but is there any interest in using rusqlite for diesel's SQLite backend instead of libsqlite3-sys directly?

[sgrif]

Hey, thanks for the PR. 0.7 requires bindgen generating at compile time rather than using the bundled bindings, right? That caused huge issues for us and we abandoned that approach for MySQL and PG.

I haven't really looked into what it would entail, but is there any interest in using rusqlite for diesel's SQLite backend

I'm not opposed to it, but IIRC your API is based off of the rust-postgres crate, correct? That makes it pretty fundamentally incompatible for us unfortunately.

[sgrif]

Oh hey it looks like you ran into all the same pains. XD /~https://github.com/jgallagher/rusqlite/pull/247

[jgallagher]

Not anymore! 0.7.0 did, but we had huge problems running bindgen at compile time too. 0.7.1 goes back to shipping prebuilt bindings (with a better system for dealing with older SQLite versions).

[sgrif]

Excellent! I will merge once CI is green. Thanks for following up!!!! <3

[jgallagher]

I'm not opposed to it, but IIRC your API is based off of the rust-postgres crate, correct? That makes it pretty fundamentally incompatible for us unfortunately.

It is, yeah. Is there a short synopsis for "fundamentally incompatible"? That seems surprising.

[sgrif]

It's been a while since I've gone into it in depth but I remember the biggest issues being Statement having a lifetime parameter attached to it, and bind parameters requiring dynamic dispatch (which basically required boxing)

[sgrif]

8996f28b might have some insights, as it's the commit where I switched to libpq for postgres

[sgrif]

I don't think having ToSql return a Result is going to work here

Lol ok past Sean, whatever you say... (I love reading old commits)

[jgallagher]

Statement having a lifetime parameter attached to it

Ah, yeah, this has come up before. Do you solve this by having statements and rows hang on to Rc'd connections? I've wondered if I could add something like that to rusqlite without duplicating a ton of code. We don't currently have a great story for "prepare this once and keep it around" other than an internal cache keyed by the query string.

and bind parameters requiring dynamic dispatch (which basically required boxing)

This one is tougher to get around, although the part of rusqlite that actually does the dynamic dispatch to bind a parameter is quite small. You want to be able to say "bind this value of a statically-known type to parameter with index N"? I'll noodle on that.

[sgrif]

Do you solve this by having statements and rows hang on to Rc'd connections?

SQLite is the only adapter where we even have to worry about that, and yeah it holds onto an Rc<Connection>. The iterator (our version of Rows more or less) takes a &mut Statement, since it actually has a known, scoped lifetime.

other than an internal cache keyed by the query string.

Yeah, that would be the standard way to do it. Ironically, the fact that we don't have to use the query string for our cache is one of our big wins, that's actually visible performance-wise on SQLite. /~https://github.com/diesel-rs/diesel/blob/master/diesel/src/connection/statement_cache.rs#L99-L105

You want to be able to say "bind this value of a statically-known type to parameter with index N

The index is less relevant (again, SQLite is a bit special here, it's the only backend where the API even cares about the index), but yeah our ToSql and FromSql are generic over the type. We work with tuples rather than slices when we have more than 1 parameter (we're looking at maybe going to hlists, but there's open RFCs that are relevant to that whole discussion #747)