You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Todd Nine <to...@spidertracks.com> on 2011/07/28 23:28:06 UTC

Questions regarding the future of CQL

Hi guys,
  I'm in the process of scheduling some time to re-work the query logic
in my Hector JPA plugin.  A lot of the documentation around CQL on the
site seems to indicate that this is the future path of the client
interfaces for Cassandra.  I have a couple of questions.

1. Will CQL ultimately replace thrift as a client api?

2. If CQL will become the interface, has any thought been given to order
by and rownum equivalent functionality in CQL?  This seems like a major
requirement for most webapps when dealing with secondary indexing and
paging.  Currently I handle this with dynamic composites, and build a
secondary query index with ordering via columns by adding order fields
between the indexed fields and the RK in my column.  Would something
like this be possible directly in Cassandra, or would Lucene style
iterators be preferred?  Personally, I prefer to take the disk space hit
and construct the ordering at the column level.

3. Do you guys feel I should focus efforts on improving the CQL
functionality then migrating the JPA plugin to it, or do you feel it is
too early to begin using the JDBC CQL drivers for this type of
functionality?

Thanks guys,
Todd



Re: Questions regarding the future of CQL

Posted by Eric Evans <ee...@rackspace.com>.
On Fri, 2011-07-29 at 09:28 +1200, Todd Nine wrote:
> 1. Will CQL ultimately replace thrift as a client api?

Personally, I don't think there is a lot of room for alternative
interfaces at this level.  Which is to say that ultimately, one will
become the de facto standard just because that's what everyone uses.
More and more that looks like it will be CQL. 

> 2. If CQL will become the interface, has any thought been given to
> order by and rownum equivalent functionality in CQL?  This seems like
> a major requirement for most webapps when dealing with secondary
> indexing and paging.  Currently I handle this with dynamic composites,
> and build a secondary query index with ordering via columns by adding
> order fields between the indexed fields and the RK in my column.
> Would something like this be possible directly in Cassandra, or would
> Lucene style iterators be preferred?  Personally, I prefer to take the
> disk space hit and construct the ordering at the column level.

If I understand what you're asking, then it doesn't sound like a CQL
issue per say.  For example, the RPC API doesn't allow reordering of row
keys because it would be prohibitively expensive in the general case,
and this is no different for CQL. 

> 3. Do you guys feel I should focus efforts on improving the CQL
> functionality then migrating the JPA plugin to it, or do you feel it
> is too early to begin using the JDBC CQL drivers for this type of
> functionality? 

Short of things like super columns, the functionality is equivalent, so
I would say go for it. 

-- 
Eric Evans
eevans@rackspace.com