SQLite libraries - Potential for Unification


#1

Right now, there are three separate projects that attempt to provide an SQLite API + bindings:

So there are three libraries with recent development activity providing basically the same thing.
dckc and stainless-stell s versions provide both lower level bindings + a higher level API, rusqlite focuses on the higher level API.

I believe this ‘fragmentation’ or duplication of efforts isn’t all that ideal.
Neither for users trying to decide which one to use, nor for potentially wasted developer time.

I’ve invited the respective authors to this thread to discuss, if they could imagine a joining of efforts.

If there’s a good reason for separate crates to exist, maybe they can be explained here, as a reference, so someone who wants to use one of them has a reference.

Please don’t see this as any kind of criticism towards the authors, I’d just like to encourage discussion.


#2

FYI, diesel uses the libsqlite3-sys crate (https://github.com/jgallagher/rusqlite) internally.


#3

I haven’t spent a ton of time investigating the other two, but I think rusqlite wraps everything they do plus considerably more (e.g., the online backup APIs and writing custom SQL functions in Rust). For a long time rusqlite didn’t provide an Iterator over query results, which made it kind of painful to use, but that was fixed with the addition of query_map in May 2015 (version 0.1).

There’s an issue on rust-sqlite3 about possibly retiring it. I can’t speak to stainless-steel/sqlite; it looks like it began well after the other two, so I’m curious if there were deficiencies in rusqlite or rust-sqlite3 at the time that it addressed.


#4

I retired mine.

Thanks, everybody, for the feedback and contributions. It’s been fun!

What’s The Right Thing to do with rust-sqlite on crates.io?


#5

yank it


#6

You could push a new version with everything marked something like

#[deprecated(note="This crate has been deprecated in favor of rusqlite")]

along with a message in the description.

I’d really recommend against yanking, breaking peoples builds without a good reason seems a bit mean to me. If there are any major security bugs, then sure yank it, but if there aren’t any issues deprecating it instead gives people some time to migrate off it.


#7

Yanking crates does not break builds. See the yank section of http://doc.crates.io/crates-io.html


#8

Only for applications that have their Cargo.lock checked in. Any libraries that depend on it will not be buildable by new developers or if used in new applications:

any future Cargo.lock files generated will not list the yanked version.


#9

That would be okay in that you don’t want libs to keep depending on abandoned software.


#10

Adding to the thread, in case someone else follows the same searches I did…

It looks like the rusqlite maintainer likely has other priorities these days - https://github.com/jgallagher/rusqlite/pull/264#issuecomment-304670030

The rust-sqlite3 crate points users to rusqlite. The most currently maintained bindings for sqlite appear to now be stainless-steel’s at https://github.com/stainless-steel/sqlite