cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <>
Subject Re: CQL Drivers
Date Thu, 25 Aug 2011 18:49:10 GMT
On Wed, Aug 24, 2011 at 11:57 PM, Jonathan Ellis <> wrote:
> The JDBC problems can be subdivided into two categories: too-tight
> coupling that having it in-tree masks (but is really a problem either
> way), and java build systems being a PITA.  By the second part I mean,
> yes, we had JDBC building after the first month or so, but it still
> required that the main Cassandra source tree be checked out and built
> locally, with a cumbersome manual process to point the driver build to
> it.
> The build headache is actually a symptom of the coupling.  None of the
> other drivers have this problem; they were forced to do things
> "right"* instead of re-using things that shouldn't be re-used.  If we
> were going to take another stab at it we should fix this first.  (More
> accurately, we should fix it anyway whether we move drivers or not.)

The other drivers never had any choice but to create their own
implementations of term encoding/decoding, which you could probably
use as an argument for us inflicting this whole mess on ourselves with
the JDBC driver.  That said, I agree that the Right solution is still
to fix the tight coupling and reuse.

> The git mirror is also a symptom of a deeper problem.  Managing the
> drivers from the same Jira system as core is awkward too.  Nor does
> three-day release voting or patch-oriented development feel like a
> good fit for CQL drivers.

I emphatically agree.

> If we're going to move the drivers out-of-tree, why not move them all
> the way to github?  We'll still be able to link "official" drivers
> from, so I'm not worried about the kind of
> fragmentation we have with Thrift clients today.  But if we want a
> little more official-ness, we could use Apache Extras on google code
> instead.  Which IMO has better bug tracker and code review systems,
> but I don't really have strong feelings either way.
> So, of the problems with the original move, the cqlsh "problem" is the
> only one that by definition can't be solved if we move the drivers out
> of tree.  I'm not enthusiastic about inflicting that on ourselves in
> exchange for problems with the git mirror.  But in exchange for a
> clean separation as a separate project?  That makes more sense to
> me.**

Setting aside my shock from a suggestion that is 1000 miles in the
opposite direction, I love it.

> * actually, relying on manual updating of Thrift is definitely
> suboptimal, but we've gotten away with it since the Thrift API hasn't
> been changing much.  A better solution might use an svn:external
> reference to the interface/ directory.  Not sure what we can do other
> than copy the .thrift file if we move to git though.

Maybe we should consider publishing releases of generated code
versioned using the VERSION constant.

> ** And yes, I do remember arguing for keeping them in-project
> originally.  Mea culpa.

Eric Evans
Acunu | | @acunu

View raw message