Cassandra support

[tupshin]

I have filed AlexPikalov/cdrs#110 so I thought I might as well file a ticket here as well.

I'm interested in adding Cassandra support to Diesel in upcoming weeks, and would love to find any interested collaborators.

From the initial poking that I've done, I don't see any design choices that would preclude using most features of diesel with a non-relational nosql store like Cassandra, but please let me know if I've missed something.
The CDRS driver is new but stabilizing quickly, and is a pure rust implementation of the CQL protocol that Cassandra uses.

The CQL language is similar to SQL, and is conceptually a subset of SQL, even though not a strict subset. It notably lacks relational joins and a number of other features, but it provides familiar SELECT FOO FROM BAR WHERE BAZ type syntax, etc.

Any thoughts/ideas/suggestions for how to tackle the integration would be welcome (I'm going to be modeling off the sqlite implementation). I'll also hang out on your gitter when I'm working on it.

[AlexPikalov]

@tupshin I could help with this stuff if there'd be an agreement that it makes sense.

[sgrif]

The process that I go through for adding a new impl is basically just pub struct NewConnection; impl Connection for NewConnection {} and then let the compiler tell me what to do next (placing unimplemented!() in the bodies of every method definition). Once that's done, I run the test suite and let the failures from unimplemented!() calls tell me where to go from there.

I'm happy to provide whatever support I can for this, but I would want this to be a third party crate, not a pull request to Diesel itself.

[tupshin]

Agree about a third party crate, and thanks, that's a very useful suggestion for how to approach it.

[tupshin]

As an out-of-tree effort, how would I go about running the test suite against my implementation?

[sgrif]

As an out-of-tree effort, how would I go about running the test suite against my implementation?

That is an excellent question that I wish I had an answer to. Short term I'd just pull down the repository, and add your crate as an optional dependency, and test locally that way.

One thing I forgot to mention is that if you do write a full adapter, you'll want it to work with Diesel CLI and Diesel Codegen. I'm fine with adding the minimal code required to add a cassandra variant to this enum and the equivalents from other crates, where the match arms basically just call out to your crate for functionality.

[sgrif]

I guess the long term answer is that you'll be the first out of tree adapter, so we'll figure something out. Once the crate gets a bit farther along we'll probably add whatever code we need to the test suite, but not run that branch on Travis (or at least put it as an allowed failure)

[tyranron]

@tupshin @AlexPikalov any news?

[AlexPikalov]

@tyranron unfortunately, no news from my side. During last months, I was involved into development of version 2 of the driver. I'd like to start working on that ASAP.