cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Pisk <>
Subject Thrift API Consolidation
Date Sat, 18 Feb 2012 02:14:29 GMT

While creating the data model for my application I came across the need to
be able to submit multiple slice predicates per row (for reasons I can
explain but I believe they are unrelated to the topic). I started digging
around the thrift api code and eventually realized that it could be
simplified while adding the ability to execute multiple row and column
slices at once.

I am proposing to replace all get operations with a single operation (I'm
going to call it get_slice for now):

map<binary, list<ColumnOrSuperColumn>> get_slice(list<KeyRange> keys,
ColumnParent column_parent, list<SlicePredicate> slices,
list<IndexExpression> index_clause, ConsistencyLevel consistency_level)

and the count equivalent:

map<binary, int32> get_slice_count(list<KeyRange> keys, ColumnParent
column_parent, list<SlicePredicate> slices, list<IndexExpression>
index_clause, ConsistencyLevel consistency_level)

Return value may also be list<KeySlice> (and the corresponding
list<KeyCount>) if the order of returned rows is important. It might be
important to keep rows in partitioner order (key order is easily
constructed on the client using TreeMap or equivalent), I do not know
enough to make that call.

For backwards compatibility existing client methods can be easily built on
top of the new method (i.e. get would become a get_slice with a single
KeyRange with the specified key being both stand and end key, a single
SlicePredicate with the specified column and null IndexClause).

Internally existing read paths would be consolidated as well. In
CassandraServer each KeyPredicate would generate a RangeSliceCommand which
would be extended (most likely by versioning similar to how ReadCommand is
subclassed) to allow multiple slice predicates. That in turn would require
QueryFilter to be extended to allow multiple slice predicates. Any code
past that (ColumnFamilyStore) will be unaffected (with calls to either
search() or getRangeSlice() now based on whether IndexClause was supplied
and there is an index for it).

All other existing read commands (SliceByNamesReadCommand,
SliceFromReadCommand and so on) would be implemented on top
of RangeSliceCommand to preserve backwards compatibility while allowing the
removal of and fetchRows(). These methods are called
directly by cql code but those calls could also be changed to effectively
execute range slices instead.

I understand this looks like a huge change but I believe that the
simplification coming from having a single read command while adding the
flexibility of multiple key and column predicates in a single call is worth

Does this seem worth doing? I would appreciate your feedback on this.


Jerry P

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message