On Wed, Aug 24, 2011 at 11:57 PM, Jonathan Ellis <jbel...@gmail.com> 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 cassandra.apache.org, 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 | http://www.acunu.com | @acunu
