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
