A QL can shield clients from a class of changes, but OTOH will make clients have to compose the query strings, where with type safe libraries this job is somewhat easier. IMO in the near term introducing a query language will make client dev somewhat harder b/c of the (somewhat negligible) work of composing query strings and mostly b/c I don't expect the QL to be stable at v1 so still a moving target, but easier in the the long term mainly due to the hope that the QL will stabilize. One other benefit of query languages is that they make tooling a little easier, one does not have to come up with a specific CLI interpreter or a web interface with a set of input fields, you just have to type your QL into a text box or a terminal like you do with sql. Long term I think I'm in for a QL (although I have to think about the syntax you suggested) but I don't expect it to benefit client devs in the near term even if it was ready today as an alternative to thrift.
One small question, does this language tunnel through avro or thrift calls? (Is >>> conn.execute() an avro or thrift call) On Thu, Nov 4, 2010 at 7:28 PM, Eric Evans <eev...@rackspace.com> wrote: > On Thu, 2010-11-04 at 09:30 -0700, Dave Viner wrote: > > 1. How does replacing thrift/avro with a SQL-inspired query language make > > the server more stable? As a client, I still need to connect via > something, > > and that something will make something like an RPC call to the server. > In > > traditional rdbms-es, this is wrapped into the connection library itself > > (e.g., odbc, perl dbi, etc). But, just by having a query language, I > don't > > think that makes the interface more "stable". It certainly might make > the > > internal code structure more stable inside Cassandra - since the "core" > > would implement the query language parser & execution engine. Then you > can > > abstract the "connection listener" into a separate piece of code > entirely. > > But, that seems like the goal/idea behind Thrift & Avro. (Note that I > am > > neither a thrift nor avro expert - so this comment is more from a basic > > concept understanding of how those libs work.) > > Simply introducing a query language doesn't, but decomposing the query > server-side as opposed to forcing the client to piece together > structures and records with typed attributes allows us to shield the > client from a whole class of changes. > > And, a query language like this isn't the *only* way to accomplish that > of course, it's just the way that seemed most appealing to me overall. > > [ ... ] > > > 3. Both Avro and Thrift have graduated to top-level apache projects. > Thrift > > did so in just the past month or two. I'm not sure exactly when Avro > did, > > but it's a top-level project now for sure. Although this provides no > > absolute guarantees, both are more likely to have longer-lived support > than > > previous non-TLP since the apache foundation is meant to stand behind > such > > projects. As a practical matter, this might be little consolation for > > previous difficulties of working with those projects/libraries, but it > > should provide some comfort for the future. > > I don't see how this has any effect one way or another, but I might be > missing something > > > I don't think I have a strong opinion one way or the other. But, I do > think > > that RPC interfaces are hard, but query language interfaces aren't much > > simpler. Just look at SQL. It took years for that to coalesce around > > common idioms and still there are incompatibilities across platforms. > > That's not to say SQL was a bad idea or isn't useful. Just that it's > not > > clear that creating a new QL isn't a recipe for solving all > > connection/interface challenges. > > I take your point, and I don't see it as a silver bullet, but this is > going to be *much* less complex than SQL. > > > -- > Eric Evans > eev...@rackspace.com > > -- /Ran
