On Thu, 14 Jan 2010 14:34:58 -0800 Tatu Saloranta <tsalora...@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.
