On Fri, Sep 24, 2010 at 8:45 AM, Chris Goffinet <c...@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
