cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Zlatanov <...@lifelogs.com>
Subject Re: "easy" interface to Cassandra
Date Fri, 15 Jan 2010 14:51:53 GMT
On Thu, 14 Jan 2010 14:34:58 -0800 Tatu Saloranta <tsaloranta@gmail.com> wrote: 

TS> No specific proposal, or immediate need. But I do know that such
TS> short-hand notations / languages are popular for accessing structured
TS> data (xpath/xquery, oql, even sql).

Sure.  The idea is to make Cassandra more accessible.  I'll try to
explain all my annoyances with the current API and why I think something
simpler is useful, specifically string-based queries.

IMHO the current API is confusing and hard to use.  ColumnPath,
ColumnParent, and ColumnOrSuperColumn (with the semi-included Column and
SuperColumn) are not obvious until you've tried to use them and failed
at least a few times.  SliceRange works inconsistently between Perl and
Java, to give another example: Perl only has 64-bit numbers in the
minority of compilations, so you have to jump through a lot of hoops to
specify the current time as 8 bytes.  The Java call for a null key to
indicate an unbounded range uses "null" while Perl (and Python and Ruby
IIRC) have to use the empty string '' which is most definitely not the
null value.

The majority of Cassandra users seem to be Java programmers so maybe
these issues simply haven't mattered to them and the rest have put
together libraries like Lazyboy and EasyCassandra.pm.

TS> Just wanted to mention that most opposition seemed to be against
TS> specific way to use such notation. Not so much for idea of more
TS> convenient access, as long as it uses facilities host language
TS> offers.

The Thrift API is exposed to a wide variety of languages.  You simply
can't use OO the same way in Perl and Haskell as you do in Java, to give
two examples.  They are ridiculously different and my issue, really, is
with the ugliness that results and with the awkward code I've had to
write in order to accomodate the current API in Perl.  OO through Thrift
is simply not good OO.[1]

So coming back to the query language, you either simulate OO queries,
which Thrift already does as badly as can be expected, or you drop down
to multiple strings, which IMHO is a bad compromise, or you use a single
string like most universal APIs in existence.  Hell, let's make the
query a RESTful HTTP GET, Cassandra a HTTP server, and return the data
as JSON if it's more palatable.  My point is, string queries are a
legitimate way to use structured data and not a Perl-specific thing.

Ted

[1] Thrift has encapsulation, sort of, but not inheritance or
polymorphism which are essential for OO.  From the Thrift FAQ:

"Thrift Features

Is struct inheritance supported?

No, it isn't. Thrift support inheritance of service interfaces, but only composition/containment
for structures.

Can I overload service methods?

Nope. Method names must be unique."

Just so it's clear, I'm not blaming Thrift, it's just a transport
mechanism.  From the days of CORBA and RMI to today's efforts (Google
Protocol Buffers and Thrift among others) it's always been like this.


Mime
View raw message