cassandra-client-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Calling all library maintainers
Date Thu, 04 Nov 2010 17:28:52 GMT
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
eevans@rackspace.com


Mime
View raw message