incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@acunu.com>
Subject CQL Drivers
Date Thu, 25 Aug 2011 00:22:59 GMT
There's been discussion happening in #2761
(https://issues.apache.org/jira/browse/CASSANDRA-2761) on and off now
for more than 3 months, and I think it could benefit from some wider
exposure.

The issue was created in the wake of the driver move from
asf/cassandra/trunk/drivers to asf/cassandra/drivers and the original
scope was to create a working build for the JDBC driver post-move (at
the time it had no build of its own).  That work has since been
completed, but it was left open to include some related items, in
hindsight it should have been closed and other issues opened as
needed.

The remainder of the discussion that's taken place in CASSANDRA-2761
revolves around moving the driver code back under Cassandra's tree.

I don't want this to happen because, as I've mentioned elsewhere,
drivers are supposed to be coded to a specification, not a Cassandra
version; Any given driver release is expected to work with any version
of Cassandra that uses a CQL version >= to that of the driver.  As
such there is a need to release them independently, with their own
versions, on a more or less frequently basis than Cassandra does.  To
this point I think there is agreement.

Where we disagree I guess is in how to accomplish this.

Moving the driver has made things less convenient in part because in
it's current location it isn't mirrored by git.apache.org, and in part
because it's quite obviously less convenient than having everything
all in one monolithic tree.  Most often cited for the latter is #3010
(https://issues.apache.org/jira/browse/CASSANDRA-3010), an issue
opened to create a CQL-based shell written in Java.

The lack of Git mirroring is unfortunate, but shouldn't be a blocker
IMO since the equivalent could be accomplished using git-svn.  I would
however be willing to do this once, for everyone, and publish the
result on Github if that would help.

As for cases like #3010, these are applications and it's no more or
less convenient than it would be for any other application.  If the
JDBC driver is unsuitable for use by us as a dependency, then it's
unsuitable for our users as well.  My suggestion here was to do what
we do with every other dependency we have and store a jar in lib/.

There are some workarounds that have been proposed for moving the
drivers back under Cassandra's source tree while creating independent
releases from there.  For example, keeping them only in trunk/ and
deleting drivers/ in new branches (which doesn't solve the case for
#3010).   In my opinion, these are half-measures that fail to create
the needed separation while making the release process brittle, or
complicated, or both, and generate confusion (which incidentally is
exactly why they were moved in the first place).

One other point that seems relevant is that all of the discussion has
centered around the JDBC driver only.  If we were to eliminate it from
the equation, it appears there'd be no (or at least a lot less)
opposition to the move.  This seems to reinforce the idea that we're
special-casing our own uses.

Thoughts? Suggestions?

--
Eric Evans
Acunu | http://www.acunu.com | @acunu

Mime
View raw message