incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: [DISCUSSION] High-volume counters in Cassandra
Date Fri, 24 Sep 2010 22:59:50 GMT
On Fri, Sep 24, 2010 at 8:45 AM, Chris Goffinet <cg@chrisgoffinet.com> wrote:
> My two cents on the issue is that, it's an important feature that the community wants,
and the work needing to be done to let 1072, isn't worth the amount of effort to delay at
this stage. I would much rather get the code in, support the feature and work towards refactoring
a better design than completely stalling the feature.

The problem is that 1072 relies on the Clock work that turns out to be
a dead end.  That happens sometimes, everyone's written code that
starts off on a path that we later realize doesn't work.  But we need
to clean out the deadwood before committing not just because it's the
right thing to do but because storing the counter in the clock
component of a column is dramatically incompatible with storing it in
the value.  It's not just a minor tweak.  As I said two weeks ago on
the ticket:

----

A major concern is that the clocks are part of the API and schema [now
just schema]. So if we commit this as-is then we have several possible
scenarios:

1. clock change gets in before 0.7.0 and everything is fine
2. clock change isn't ready for 0.7.0 and we block 0.7.0 for it
3. clock change isn't ready for 0.7.0, we release anyway, and break
compatibility w/ the next release
4. clock change isn't ready for 0.7.0 so we postpone it until 0.8
(thus having to maintain both versions until 0.7 is obsolete)

----

2-4 are bad enough risks that it's worth taking the time to get it
right before committing it.

-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com

Mime
View raw message