Test CQL binding with Cassandra 2.1

[busbey]

I believe Cassandra 2.1 is the current stable line. We know the CQL binding works with a Cassandra 2.0 cluster, need to try for 2.1.

[busbey]

Note that we have confirmed accounts of not working on 2.1+

[cmccoy]

I have a patch (cmccoy@3e8d7bb1aa314e42e65161ede4d8a260e51979e6), but it's a bit awkward - the incompatibility in the current implementation is that Cluster#shutdown() has been renamed Cluster#close(), so I added an abstract CQL client with an overridable cleanup method - for < 2.0 it's Cluster#shutdown(), for >= 2.0 it's Cluster#close().

Anyone have a cleaner idea?

[cmatser]

Does the old method compile with the new code... with some sort of deprecated warning? or does it fail to build with the >= 2.0 cassandra libraries?

I'm wondering if we can create a property which defaults to the newer >= 2.0 method, but can be set to use the older <2.0 if desired. Some sort of "cassandra_pre2=true|false" property. Would that be cleaner?

Otherwise, you're talking about two different clients in the concrete classes, yes? Something like CassandraCQLClientGreaterThanOrEqual2_0 and CassandraCQLClientLessThan2_0 would have to be specified on the run command line. (Obviously we'd pick better names. :) )

What is the issue that you feel what you have is not quite a clean solution?

Thanks for tracking this down, btw!

[cmccoy]

Does the old method compile with the new code... with some sort of deprecated warning? or does it fail to build with the >= 2.0 cassandra libraries?

No, it fails to compile. And it turns out my solution doesn't work - the signature for Session#execute(...) also changed, so the CQL common code can't be compiled to work with both 2.0 and 1.0.

I don't like to do this, but maybe we should just duplicate the CQL binding targeting a new database cassandra2, as has been done for HBase.

[cmccoy]

Thanks for tracking this down, btw!

Credit to #204 :)

[cmccoy]

Closed by #454.