Hi Timmy,
I see what you mean. No, I don't have any plans to do that -- in fact,
it seems like it would be exceedingly difficult, as CQL2 doesn't
support composite column comparators, which as I understand it
underlie the multi-primary-key structures in CQL3. Might be possible
to hand-roll something into a blob but seems like a bit of a pain!
Mat
On Wed, Nov 21, 2012 at 2:40 AM, Timmy Turner timm.t...@gmail.com wrote:
Thanks Mat!
I thought you were going to expose the internals of CQL3 features like (wide
rows with) complex keys and collections to CQL2 clients (which is something
that should generally be possible, if Datastax' blog posts are accurate,
i.e. an actual description of how things were implemented and not just a
conceptual one).
I'm still negotiating with my project lead on what features will ultimately
be implemented, so I'm not sure whether CQL2/3 interoperability will
actually make it into the final 'product' .. but it isn't very high up on
the priority list, so it will most likely be implemented towards the end,
and thus I guess it'll also kind of depend on how much CQL2 support will be
provided by Cassandra itself when the time comes.
2012/11/20 Mat Brown m...@brewster.com
Hi Timmy,
I haven't done a lot of playing with CQL3 yet, mostly just reading the
blog posts, so the following is subject to change : )
Right now, the Cequel model layer has a skinny row model (which is
designed to follow common patterns of Ruby ORMs) and a wide row model
(which is designed to behave more or less like a Hash, the equivalent
of Java's HashMap). The two don't integrate with each other in any
meaningful way, but as far as I understand it, they do pretty much
cover the data modeling possibilities in CQL2.
The big idea I've got for the overhaul of Cequel for CQL3 is to allow
building a rich, nested data model by integrating different flavors of
CQL3 table, most notably multi-column primary keys, as well as
collections. The core data types I have in mind are:
1) Skinny row with simple primary key (e.g. blogs, with blog_id key)
2) Skinny row with complex primary key (e.g. blog_posts, with
(blog_id, post_id) key)
3) Wide row with simple primary key (e.g. blog_languages -- kind of a
weak example but i can't think of anything better for a blog : )
4) Wide row with complex primary key (e.g. blog_post_tags)
My goal is to make it easy to model one-one relationships via a shared
primary key, and one-many via a shared prefix of the primary key. So,
for instance, blogs and blog_languages rows would be one-one (both
with a blog_id primary key) and blogs and blog_posts would be one-many
(sharing the blog_id prefix in the primary key).
From what I've read, it seems fairly clear that the actual CQL used to
interact with #1 will be the same for CQL2 column families and CQL3
tables, so no explicit backward compatibility would be needed. #2 and
#4 are, of course, CQL3-only, so backward compatibility isn't an issue
there either. What I'm not entirely clear on is #3 -- this is
straightforward in CQL2, and presumably a CQL3 table with compact
storage would behave in the same way. However, my understanding so far
is that a non-compact CQL3 table would treat this structure
differently, in that both the key and value of the map would
correspond to columns in a CQL3 table. It may make more sense to just
target compact storage tables with this data structure, but I'm going
to need to play around with it more to figure that out. Otherwise,
Cequel will need to provide two flavors of that structure.
There's also some tension between CQL3 collections and just using
traditional wide-row structures to achieve the same thing. For
instance, blog_tags could also just be a tags collection in the blogs
table. My plan at this point is to offer both options, since each has
its advantages (collections don't require the creation of a separate
table; but a separate table gives you access to slices of the
collection).
Anyway, that's probably a lot more of an answer than you needed, but
hopefully the context helps. Definitely interested to hear about the
direction you take your client in as well.
Finally, regarding a blog, we've got one set up, but it's not live
yet. I'll ping you with a link when it is; I'll certainly be posting
on the development of the next Cequel release.
Cheers,
Mat
On Tue, Nov 20, 2012 at 9:23 AM, Timmy Turner timm.t...@gmail.com wrote:
@Mat Brown:
(while still retaining compatibility with CQL2 structures).
Do you mean by exceeding what Cassandra itself provides in terms of
CQL2/3
interoperability?
I'm looking into something similar currently (however in Java not in
Ruby)
and would be interested in your experiences, if you follow through with
the
plan. Do you have a blog?
Thanks!
2012/11/20 Alain RODRIGUEZ arodr...@gmail.com
@Mat
Well I guess you could add your Ruby client to this list since there is
