Evaluate making a full featured DBI interface for Rust

[linuxfood]

So this was just an idea that popped into my head at some point and I figured I should jot it down.

If nobody else is working on making a DBI interface for Rust (similar to, but perhaps a little more coherent than Perl DBI: http://dbi.perl.org/ ), we might be in a pretty cool spot to think about that.

@kud1ing do you have any thoughts or interest? :)

[kud1ing]

That would be interesting. I can not commit myself to bigger tasks though, since my free time is somewhat limited.

[linuxfood]

I probably have time to sketch up a basic idea of what a Rust-y DBI library would look like, having used quite a few of them over the years in various languages. I can't particularly commit to being able to implement anything, but, I can probably get something written down design-wise to talk about.

[kud1ing]

That would be quite helpful

[kud1ing]

See also https://github.com/sfackler/rust-postgres

[kud1ing]

CC @sfackler

[sfackler]

I looked into making one a while ago. There are still some technical issues preventing a reasonable API currently. We'd (I think) want something like

pub trait Connection<Err, Res, TS, Stmt: Statement<Err, Res, TS>> {
    fn prepare<'a>(&'a self, stmt: &str) -> Result<Stmt<'a>, Err>;
    ...
}

pub trait Statement<Err, Res, TS: ToSql> {
    fn query<'a>(&'a self, params: &[&TS]) -> Result<Res<'a>, Err>;
    fn update<'a>(&'a self, params: &[&TS]) -> Result<uint, Err>;
    ...
}

...etc...

The important part there is the lifetimes. There's currently no way to express the idea that a parameterized trait method returns a parameterized type with a lifetime bound. This is filed as rust-lang/rust#8973.

There are also some interesting questions of how to do things like the ToSql trait in a way that's generic enough.

[brianoh]

I'm sure you have looked at it, however just in case: are you looking at anything similar to what the database/sql package in Go offers? I haven't studied how it works, but it does provide a uniform way of accessing sql databases which solves a lot of problems in terms of uniformity when using different drivers.

http://golang.org/pkg/database/sql/

[sfackler]

@brianoh: that's what I was talking about above. Something I'd like to focus on there is to make sure that the API ends up being reasonable if you want to use it generically or you know you're always going to be using Postgres or SQLite or whatever. Picking a minimum shared set of functionality can be a challenge, especially since SQLite takes a different tack than many other SQL databases with regard to types, etc.

[brianoh]

Ok, that's good to know. Personally, I would likely treat SQLite as a
special-case. If it can be included, well and good. If there were to be
trade-offs, I'd likely exclude it. After all, it is a desktop database
rather than a server database. That's not to denigrate it, because it
obviously has filled a needed niche.

On Sat, Oct 26, 2013 at 3:09 PM, Steven Fackler notifications@github.comwrote:

@brianoh https://github.com/brianoh: that's what I was talking about
above. Something I'd like to focus on there is to make sure that the API
ends up being reasonable if you want to use it generically or you know
you're always going to be using Postgres or SQLite or whatever. Picking a
minimum shared set of functionality can be a challenge, especially since
SQLite takes a different tack than many other SQL databases with regard to
types, etc.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-27139088
.

[kud1ing]

See also https://mail.mozilla.org/pipermail/rust-dev/2013-December/007332.html

[kud1ing]

See also rust-lang/rust#14658

I've commented in rust-lang/rust#14658 about SOCI (http://soci.sourceforge.net/) which I've had good experiences with.

[kud1ing]

@Eli-Green: Thank you.
I tend to close this issue here, since the Rust-wide initiative has more momentum.