You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Ted Zlatanov <tz...@lifelogs.com> on 2009/12/28 17:42:43 UTC
EasyCassandra.pm Perl interface alpha 0.01
Attached is the first alpha (0.01) version of my EasyCassandra.pm Perl
interface to Cassandra. I am also attaching a demo script that will
show the intended usage, but basically the idea is that the user can
express gets, puts, and removals in shorthand like "Subscribed/<-1>[]"
to mean the latest Subscribed super column, all columns. Please look at
the easydemo.pl script to see the exact syntax; the EasyCassandra.pm
module has a full list of all the acceptable specifications.
There are some TODO items and I can probably optimize the code so it
doesn't use multiget_slice() for everything. Also the code to retrieve
all row keys and all the super columns (when they are more than the
usual 100 limit) is hacky. Nevertheless, this is IMHO about 10x easier
to use than the auto-generated Perl modules, and 5x easier than
Net::Cassandra on CPAN.
You'll need Moose, Class::Accessor, Parse::RecDescent and Hash::Merge
from CPAN, plus all the Thrift auto-generated Perl code.
For those who are interested, the grammar generates all the parameters
for removals and insertions on the fly as it parses the specification.
It wasn't as easy to generate read parameters on the fly so I
post-generate those from the parse tree.
Consider this an alpha, released for public testing before I upload it
to CPAN in a week or two. I would appreciate any suggestions or
comments, especially on the grammar and API usage.
Thanks
Ted
Re: "easy" interface to Cassandra
Posted by Brandon Williams <dr...@gmail.com>.
2010/1/12 Ted Zlatanov <tz...@lifelogs.com>
> Map latest = client.get(new String[] { "row1" }, "Values/<-1>[]");
>
Reminds me of the old colon-separated CF format. I'm not fond of passing
parameters to my functions that have their own special syntax. +1 to
language-specific idiomaticness instead.
-Brandon
Re: "easy" interface to Cassandra
Posted by philip schlump <ps...@gmail.com>.
My application uses cassandra in this way - basically a HTTP RESTful
interface for the data and
it is returned in JSON format. I would be super interested in anything that
would eliminate my
custom python code for doing this. Basically I just hard-coded the stuff
that I needed - but a
flexible (even a little flexible) way of getting the same job done would be
super useful!
2010/1/15 Ted Zlatanov <tz...@lifelogs.com>
> On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta <ts...@gmail.com>
> wrote:
>
> TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
> >> 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
>
> TS> No contest there. :-)
>
> If anyone, including you, is interested, I could put together a patch to
> show how Cassandra would respond to REST HTTP queries with JSON-encoded
> data. Based on the feedback so far it seems like it wouldn't make it in
> the core, though.
>
> I could provide a way to plug in your own API to Cassandra so anyone
> could write a full API using PB, HTTP, or whatever protocol they like.
> Underneath it could invoke the Thrift interface methods locally and
> relay their results out. This would be really nice but again I doubt it
> would be included in the core.
>
> Ted
>
>
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
Ted Zlatanov wrote:
>>> I've got three (me, Tatu, Philip) in favor of such an interface.
>>> Jonathan, Eric, anyone else, WDYT?
>>>
>>> My proposal is as follows:
>>>
>>> - provide an IPluggableAPI interface; classes that implement it are
>>> essentially standalone Cassandra servers. Maybe this can just
>>> parallel Thread and implement Runnable.
>>>
>>> - enable the users to specify which IPluggableAPI they want and provide
>>> instantiation options (port, connection limit, etc.)
>>>
>>> - write a simple HTTPPluggableAPI, which provides a web server and
>>> accepts POST requests. The exact path and option spec can be worked
>>> out later. The input and output formats can be specified with a query
>>> parameter; at least JSON and XML should be supported.
On Tue, Jan 19, 2010 at 6:13 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> I'm a huge non-fan of the "let's specify everything in as minute
> detail as possible before writing anything" style that resulted in
> CASSANDRA-547 taking about ten times as long as necessary. Code
> something up, if the approach has merit, it can be refined.
All right, thanks for the feedback.
Ted
Re: "easy" interface to Cassandra
Posted by Jeff Hodges <jh...@twitter.com>.
+1
--
Jeff
On Tue, Jan 19, 2010 at 6:13 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> I'm a huge non-fan of the "let's specify everything in as minute
> detail as possible before writing anything" style that resulted in
> CASSANDRA-547 taking about ten times as long as necessary. Code
> something up, if the approach has merit, it can be refined.
>
> -Jonathan
>
> 2010/1/19 Ted Zlatanov <tz...@lifelogs.com>:
>> On Mon, 18 Jan 2010 10:48:41 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
>>
>> TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
>>>> I could provide a way to plug in your own API to Cassandra so anyone
>>>> could write a full API using PB, HTTP, or whatever protocol they like.
>>>> Underneath it could invoke the Thrift interface methods locally and
>>>> relay their results out. This would be really nice but again I doubt it
>>>> would be included in the core.
>>
>> TS> I would find it useful to have such an alternative interface. I have
>> TS> nothing against Thrift, but there are cases where simpler interface
>> TS> would be useful. And in those cases it would be fine to have this as
>> TS> sort of adapter.
>>
>> TS> For what it's worth, I think it would be nice to keep the two
>> TS> (transport over http, contents as json) separate, if possible. I like
>> TS> JSON, but there are use cases where other formats are better.
>> TS> For numeric data, for example, binary formats are more compact.
>>
>> I've got three (me, Tatu, Philip) in favor of such an interface.
>> Jonathan, Eric, anyone else, WDYT?
>>
>> My proposal is as follows:
>>
>> - provide an IPluggableAPI interface; classes that implement it are
>> essentially standalone Cassandra servers. Maybe this can just
>> parallel Thread and implement Runnable.
>>
>> - enable the users to specify which IPluggableAPI they want and provide
>> instantiation options (port, connection limit, etc.)
>>
>> - write a simple HTTPPluggableAPI, which provides a web server and
>> accepts POST requests. The exact path and option spec can be worked
>> out later. The input and output formats can be specified with a query
>> parameter; at least JSON and XML should be supported.
>>
>> Ted
>>
>>
>
Re: "easy" interface to Cassandra
Posted by Jonathan Ellis <jb...@gmail.com>.
I'm a huge non-fan of the "let's specify everything in as minute
detail as possible before writing anything" style that resulted in
CASSANDRA-547 taking about ten times as long as necessary. Code
something up, if the approach has merit, it can be refined.
-Jonathan
2010/1/19 Ted Zlatanov <tz...@lifelogs.com>:
> On Mon, 18 Jan 2010 10:48:41 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
>
> TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
>>> I could provide a way to plug in your own API to Cassandra so anyone
>>> could write a full API using PB, HTTP, or whatever protocol they like.
>>> Underneath it could invoke the Thrift interface methods locally and
>>> relay their results out. This would be really nice but again I doubt it
>>> would be included in the core.
>
> TS> I would find it useful to have such an alternative interface. I have
> TS> nothing against Thrift, but there are cases where simpler interface
> TS> would be useful. And in those cases it would be fine to have this as
> TS> sort of adapter.
>
> TS> For what it's worth, I think it would be nice to keep the two
> TS> (transport over http, contents as json) separate, if possible. I like
> TS> JSON, but there are use cases where other formats are better.
> TS> For numeric data, for example, binary formats are more compact.
>
> I've got three (me, Tatu, Philip) in favor of such an interface.
> Jonathan, Eric, anyone else, WDYT?
>
> My proposal is as follows:
>
> - provide an IPluggableAPI interface; classes that implement it are
> essentially standalone Cassandra servers. Maybe this can just
> parallel Thread and implement Runnable.
>
> - enable the users to specify which IPluggableAPI they want and provide
> instantiation options (port, connection limit, etc.)
>
> - write a simple HTTPPluggableAPI, which provides a web server and
> accepts POST requests. The exact path and option spec can be worked
> out later. The input and output formats can be specified with a query
> parameter; at least JSON and XML should be supported.
>
> Ted
>
>
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Tue, 19 Jan 2010 08:09:13 -0600 Ted Zlatanov <tz...@lifelogs.com> wrote:
TZ> My proposal is as follows:
TZ> - provide an IPluggableAPI interface; classes that implement it are
TZ> essentially standalone Cassandra servers. Maybe this can just
TZ> parallel Thread and implement Runnable.
TZ> - enable the users to specify which IPluggableAPI they want and provide
TZ> instantiation options (port, connection limit, etc.)
TZ> - write a simple HTTPPluggableAPI, which provides a web server and
TZ> accepts POST requests. The exact path and option spec can be worked
TZ> out later. The input and output formats can be specified with a query
TZ> parameter; at least JSON and XML should be supported.
First very rough proposal is at
https://issues.apache.org/jira/browse/CASSANDRA-754
Ted
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Mon, 18 Jan 2010 10:48:41 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
>> I could provide a way to plug in your own API to Cassandra so anyone
>> could write a full API using PB, HTTP, or whatever protocol they like.
>> Underneath it could invoke the Thrift interface methods locally and
>> relay their results out. This would be really nice but again I doubt it
>> would be included in the core.
TS> I would find it useful to have such an alternative interface. I have
TS> nothing against Thrift, but there are cases where simpler interface
TS> would be useful. And in those cases it would be fine to have this as
TS> sort of adapter.
TS> For what it's worth, I think it would be nice to keep the two
TS> (transport over http, contents as json) separate, if possible. I like
TS> JSON, but there are use cases where other formats are better.
TS> For numeric data, for example, binary formats are more compact.
I've got three (me, Tatu, Philip) in favor of such an interface.
Jonathan, Eric, anyone else, WDYT?
My proposal is as follows:
- provide an IPluggableAPI interface; classes that implement it are
essentially standalone Cassandra servers. Maybe this can just
parallel Thread and implement Runnable.
- enable the users to specify which IPluggableAPI they want and provide
instantiation options (port, connection limit, etc.)
- write a simple HTTPPluggableAPI, which provides a web server and
accepts POST requests. The exact path and option spec can be worked
out later. The input and output formats can be specified with a query
parameter; at least JSON and XML should be supported.
Ted
Re: "easy" interface to Cassandra
Posted by Tatu Saloranta <ts...@gmail.com>.
2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
> On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
>
> TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
>>> 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
>
> TS> No contest there. :-)
>
> If anyone, including you, is interested, I could put together a patch to
> show how Cassandra would respond to REST HTTP queries with JSON-encoded
> data. Based on the feedback so far it seems like it wouldn't make it in
> the core, though.
>
> I could provide a way to plug in your own API to Cassandra so anyone
> could write a full API using PB, HTTP, or whatever protocol they like.
> Underneath it could invoke the Thrift interface methods locally and
> relay their results out. This would be really nice but again I doubt it
> would be included in the core.
I would find it useful to have such an alternative interface. I have
nothing against Thrift, but there are cases where simpler interface
would be useful. And in those cases it would be fine to have this as
sort of adapter.
For what it's worth, I think it would be nice to keep the two
(transport over http, contents as json) separate, if possible. I like
JSON, but there are use cases where other formats are better.
For numeric data, for example, binary formats are more compact.
-+ Tatu +-
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
TS> 2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
>> 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
TS> No contest there. :-)
If anyone, including you, is interested, I could put together a patch to
show how Cassandra would respond to REST HTTP queries with JSON-encoded
data. Based on the feedback so far it seems like it wouldn't make it in
the core, though.
I could provide a way to plug in your own API to Cassandra so anyone
could write a full API using PB, HTTP, or whatever protocol they like.
Underneath it could invoke the Thrift interface methods locally and
relay their results out. This would be really nice but again I doubt it
would be included in the core.
Ted
Re: "easy" interface to Cassandra
Posted by Tatu Saloranta <ts...@gmail.com>.
2010/1/15 Ted Zlatanov <tz...@lifelogs.com>:
...
> 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 +-
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Thu, 14 Jan 2010 14:34:58 -0800 Tatu Saloranta <ts...@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.
Re: "easy" interface to Cassandra
Posted by Tatu Saloranta <ts...@gmail.com>.
2010/1/14 Ted Zlatanov <tz...@lifelogs.com>:
> On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
>
> TS> I think there are 2 separate questions:
>
> TS> (a) Would a path language make sense, and
> TS> (b) How would that be exposed
>
> TS> So I think more developers would be opposed to part (b) of exposing
> TS> path queries using opaque things like Strings, in languages where
> TS> other abstractions can be used.
>
> TS> But it might be that the concept of path-based queries makes sense,
> TS> just using more typed building blocks, to make access more natural for
> TS> language in question.
>
> Based on the feedback I got, I don't think anyone is interested. If you
> have a proposal, though, I'm all ears. My "easy" solution was certainly
> not the only possible one to simplify path queries.
No specific proposal, or immediate need. But I do know that such
short-hand notations / languages are popular for accessing structured
data (xpath/xquery, oql, even sql).
Just wanted to mention that most opposition seemed to be against
specific way to use such notation. Not so much for idea of more
convenient access, as long as it uses facilities host language offers.
-+ Tatu +-
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta <ts...@gmail.com> wrote:
TS> I think there are 2 separate questions:
TS> (a) Would a path language make sense, and
TS> (b) How would that be exposed
TS> So I think more developers would be opposed to part (b) of exposing
TS> path queries using opaque things like Strings, in languages where
TS> other abstractions can be used.
TS> But it might be that the concept of path-based queries makes sense,
TS> just using more typed building blocks, to make access more natural for
TS> language in question.
Based on the feedback I got, I don't think anyone is interested. If you
have a proposal, though, I'm all ears. My "easy" solution was certainly
not the only possible one to simplify path queries.
Ted
Re: "easy" interface to Cassandra
Posted by Tatu Saloranta <ts...@gmail.com>.
2010/1/13 Ted Zlatanov <tz...@lifelogs.com>:
> On Wed, 13 Jan 2010 08:05:45 +1300 Michael Koziarski <mi...@koziarski.com> wrote:
>
>>> I see no value in pushing for ports of a Perl library to other
>>> languages instead of allowing each to grow its own idiomatic one.
>
> MK> That's definitely the way to go, the Easy.pm magic strings look a
> MK> little like line noise to me ( a non-perler )
>
> Thanks for the feedback. I'll keep EasyCassandra Perl-only.
I think there are 2 separate questions:
(a) Would a path language make sense, and
(b) How would that be exposed
So I think more developers would be opposed to part (b) of exposing
path queries using opaque things like Strings, in languages where
other abstractions can be used.
But it might be that the concept of path-based queries makes sense,
just using more typed building blocks, to make access more natural for
language in question.
Anyway, just my 2c,
-+ Tatu +-
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Wed, 13 Jan 2010 08:05:45 +1300 Michael Koziarski <mi...@koziarski.com> wrote:
>> I see no value in pushing for ports of a Perl library to other
>> languages instead of allowing each to grow its own idiomatic one.
MK> That's definitely the way to go, the Easy.pm magic strings look a
MK> little like line noise to me ( a non-perler )
Thanks for the feedback. I'll keep EasyCassandra Perl-only.
Ted
Re: "easy" interface to Cassandra
Posted by Michael Koziarski <mi...@koziarski.com>.
> I see no value in pushing for ports of a Perl library to other
> languages instead of allowing each to grow its own idiomatic one.
That's definitely the way to go, the Easy.pm magic strings look a
little like line noise to me ( a non-perler ) and I'm sure the
invocations in the cassandra gem look similarly strange to
non-rubyists.
http://github.com/fauna/cassandra
--
Cheers
Koz
Re: "easy" interface to Cassandra
Posted by Jonathan Ellis <jb...@gmail.com>.
2010/1/12 Ted Zlatanov <tz...@lifelogs.com>:
> If no one else sees value in it, I'll keep the "easy" interface as a
> Perl module and release on CPAN. Can I get some more opinions?
I see no value in pushing for ports of a Perl library to other
languages instead of allowing each to grow its own idiomatic one.
-Jonathan
Re: "easy" interface to Cassandra
Posted by Ted Zlatanov <tz...@lifelogs.com>.
On Sun, 10 Jan 2010 11:16:20 +0000 Mark Robson <ma...@gmail.com> wrote:
MR> I can't see any reason to make an "easy" Cassandra interface, as the Thrift
MR> interface isn't really very difficult.
Compare this (this is what the "easy" interface would look like in Java,
wrapped in try/catch of course):
EasyCassandra client = new EasyCassandra("cassandraserver", "thekeyspace");
client.connect();
Map latest = client.get(new String[] { "row1" }, "Values/<-1>[]");
to the equivalent Thrift calls to connect to the server, specify you
want row "row1", supercolumn family "Values", last supercolumn, and get
all the columns as a Map. I think this interface is significantly
easier.
MR> In any case the main problems with Cassandra will be design ones, i.e.
MR> figuring out how to use it effectively in your application. No "Easy"
MR> library is going to make that easier.
I agree that learning how to use Cassandra effectively is an issue, but
constructing the API calls is pretty laborious. Especially in Perl it's
unnecessarily painful in my experience. I think this presents a barrier
to adoption.
For my work, the "easy" interface has shortened my code, allowed me to
write quick one-liners for targeted data extraction, and enabled me to
experiment with Cassandra more freely.
If no one else sees value in it, I'll keep the "easy" interface as a
Perl module and release on CPAN. Can I get some more opinions?
Thanks
Ted
Re: "easy" interface to Cassandra (was: EasyCassandra.pm Perl
interface alpha 0.01)
Posted by Mark Robson <ma...@gmail.com>.
I can't see any reason to make an "easy" Cassandra interface, as the Thrift
interface isn't really very difficult.
In any case the main problems with Cassandra will be design ones, i.e.
figuring out how to use it effectively in your application. No "Easy"
library is going to make that easier.
Mark
"easy" interface to Cassandra (was: EasyCassandra.pm Perl interface alpha 0.01)
Posted by Ted Zlatanov <tz...@lifelogs.com>.
I was wondering if it would make sense to add the pseudo-language
EasyCassandra.pm uses right into Cassandra and expose it over Thrift.
Here's a summary of the requests supported by this language:
# read and remove requests:
# "X/[Y][A,B]": supercolumn family X, super column Y (not a timestamp), columns A and B
# "X/[Y][]": supercolumn family X, super column Y (not a timestamp), all columns
# "X/{1234567890}[A,B]": supercolumn family X, timestamp numeric super column (packed to 8 bytes), columns A and B
# "X/{1234567890}[]": supercolumn family X, timestamp numeric super column (packed to 8 bytes), all columns
# "X/{}[A,B]": supercolumn family X, all the super columns, columns A and B (but all will be returned or removed)
# "X/{}[]": supercolumn family X, all the super columns, all columns
# "X[]": column family X, all columns
# "X[A,B]": column family X, columns A and B
# super column ranges work as expected, with commas:
# "X/[Y,Z][]": supercolumn family X, super columns Y and Z (not a timestamp), all columns
# "X/{1234567890,1234567891}[A,B]": supercolumn family X, two timestamp numeric super column (packed to 8 bytes), columns A and B
# read only requests (positional requests are only for reading)
# "X/<0>[A,B]": supercolumn family X, first super column, columns A and B (but all will be returned)
# "X/<0>[]": supercolumn family X, first super column, all columns
# "X/<4>[A,B]": supercolumn family X, fourth super column, columns A and B (but all will be returned)
# "X/<4>[]": supercolumn family X, fourth super column, all columns
# "X/<-3>[A,B]": supercolumn family X, last three super columns, columns A and B (but all will be returned)
# "X/<-3>[]": supercolumn family X, last three super columns, all columns
# "X/<-1>[A,B]": supercolumn family X, last super column, columns A and B (but all will be returned)
# write requests:
# "X/Y[Z]": supercolumn family X, super column Y (not a timestamp), column Z
# "X/{1234567890}[Z]": supercolumn family X, timestamp numeric super column (packed to 8 bytes), column Z
# "X/{}[Z]": supercolumn family X, current timestamp numeric super column (packed to 8 bytes), column Z
# "X[Y]": column family X, column Y
All the data is passed around with maps. While this won't work for
every use case, I think for a large number it will be sufficient. At
least for my needs it has worked very well. Especially for scripting
languages like Perl, Ruby, or Python, this is a convenient way to write
one-liners: you don't need the whole Thrift class hierarchy, just the
get/set/remove calls, and you don't need to worry about ranges, which
makes the client code simpler (results can be returned iterator-style if
performance is a concern). In fact this can be a second Thrift
interface to Cassandra, also implemented by CassandraServer but
completely independent of the primary so each of the two interfaces
won't be affected by any changes to the other.
If this is interesting I can put a prototype together with ANTLR.
Ted