cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <>
Subject Re: "easy" interface to Cassandra
Date Fri, 15 Jan 2010 17:23:08 GMT
2010/1/15 Ted Zlatanov <>:
> 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

Right. Or use per-language bindings for more specialised solutions (or
combinations thereof).

> 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

No contest there. :-)

> 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:

True. But I am still on the fence where these need to be supported for
data conversion level.
As with object/relational impedance, object/data-format impedance can
be solved multiple ways, and not all of those include hi-fi handling
of all OO features (beyond polymorphism and inheritance, there's of
course the tricky question of object identity to tackle).

But I digress. :)

> 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.

This is big part of why I am not big fan of integrated solutions. It
would seem that there is genuine need for layer that does handle
connectivity/transmit issue, but that does not force use of specific
in-built serialization scheme. I do not know much about Thrift so I
hope I am not off-base here, but it would be nice to separate these
concerns. There are plenty of good data binding choices that can
handle more varied object types than Thrift or PB. For some uses,
high-compactness and good performance favor binary encodings and/or
code generation. For others more dynamic choices are better.

-+ Tatu +-

View raw message