RFC IDEA: Rust Database API

[DanielFath]

It would be a nice unified API for databases akin to what Java ecosystem has. Were there any discussions/RFCs on this topic before? Is this something that is of interest to wider Rust community?

I’d personally would love for there to be a way to have a unified interface to run queries and execute statements, manage transactions, isolation levels, etc.

[thramp]

A few questions!

• Will this only handle relational databases? My concern is that if we prefer relational databases, we’ll be leaving out many non-relational datastores.
• Will this API be committing to a wire format, or a set of traits that database adapters should implement?

(I can’t think of anything else a the moment.)

[drXor]

I’m not sure if this is something that Rust should commit to? It’s sufficiently abstracted from OS or language facilities that it should probably not be mandated by the language. Plus, diesel seems to have popped up as a vaguely canonical tool (not that I’ve ever used it).

There’s many archtypes of databases out there (relational, columnar, etc), and I think attempting to capture them all in a single crate is intractable, and might result in kitchen-sink syndrome.

[josh]

This seems like something easily developed within the crate ecosystem. Create a crate with a common API, and get people to build interfaces to various databases via that API.

Note that Rust already has several ODBC crates, for instance.

[DanielFath]

Will this only handle relational databases? My concern is that if we prefer relational databases, we’ll be leaving out many non-relational datastores.

Yes, I meant this only for relational databases. As far as I’m aware, non-relational datastores don’t have a single unifying concepts such as transactions, connections, rows, columns, etc.

Will this API be committing to a wire format, or a set of traits that database adapters should implement?

I don’t believe so. I’d imagine it would be a set of common interfaces all database drivers would agree to implement.

This seems like something easily developed within the crate ecosystem. Create a crate with a common API, and get people to build interfaces to various databases via that API.

I don’t believe this is the case. Right now we have a bunch of different implementation with their own custom drivers - see example rust-postgres, sqlite, mysql, and diesel* that essentially implement their own drivers.

Without standardization on some level, everyone that wants to write some database middleware needs to write their own drivers or create adapters for each existing drivers. For example, if I want to write something akin to jooQ in Rust, I need to rewrite the drivers from scratch, fork existing drivers or try to fit a round peg through a square hole.

* diesel reuses some low level drivers from sqlite crate.

[Nemo157]

I don’t believe this is the case. Right now we have a bunch of different implementation with their own custom drivers - see example rust-postgres, sqlite, mysql, and diesel * that essentially implements its own drivers.

I think what @josh was getting at is that it would be entirely possible to prototype this outside the standard library. There’s no need for an RFC or Rust core developers involvement.

It’s even possible to prototype it without having to change those libraries, you could create an interface crate like sql-driver containing the traits, then create adapters like rust-postgres-sql-driver implementing the traits for each existing driver.

It’s probably better to discuss with the developers of the current database drivers first, but doing this sort of out-of-tree prototyping could allow faster iteration without having to change the existing libraries.

EDIT: As an example of this there’s a tls-api ecosystem around integrating different TLS implementations into a common trait system.

[DanielFath]

I think what @josh was getting at is that it would be entirely possible to prototype this outside the standard library. There’s no need for an RFC or Rust core developers involvement.

Oh, I agree, I’m just wondering:

1. Is there interest?
2. Would anyone else want to do it?
3. What would be the requirements (async or sync what enums should we have, and the overall shape of the API)?
4. Should we have RFC for such project? (I lean towards yes)

[theduke]

The GO sql pacakge can be an inspiration here. It’s in the std lib and basically everyone uses it.

I’m worried though that the Rust type system is too complex for something like this to work well or be generic enough to cover all uses cases well. (Think: references, generics, etc).

For example, this would probably be pretty useless for diesel due to it’s heavy use of generics all over the place.

[DanielFath]

I’m worried though that the Rust type system is too complex for something like this to work well or be generic enough to cover all uses cases well. (Think: references, generics, etc).

For example, this would probably be pretty useless for diesel due to it’s heavy use of generics all over the place.

Yeah, I too worry it might be too hard to implement such interface. Ideally, it would be possible to extract common low level interface which diesel could use.

I wonder if @sgrif could chime in and describe a low level interface he could use in diesel.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.