Diesel: Cassandra support

[tupshin]

I have filed https://github.com/AlexPikalov/cdrs/issues/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.

[piyushwadhwani]

any news or updates on this

[weiznich]

@piyushwadhwani Not from diesels side. We are continue to have the opinion that this should start as third party backend. The only thing that changed here is that there is now at least one working third party backend, showing that it is possible to implement such a thing outside of diesel.

I close this issue as this is not something actionable for diesel itself. That does explicitly not mean that this issue shouldn't be used to discuss the state of such a potential third party backend, just that this isn't something we are planing to work on in diesel itself.