Build failed in Hudson: Cassandra #530

See -- [...truncated 1535 lines...] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.128 sec [junit] [junit] Cobertura: Loaded information on 932 classes. [junit] Cobertura:

Re: [DISCUSSION] High-volume counters in Cassandra

On Thu, Sep 2, 2010 at 4:10 PM, Torsten Curdt wrote: > The feature could still be marked experimental. > That should loosen the contract a little. But at least it would be > something to work with. Maybe this is the best approach, post- code cleanup. Although I'm reluctant to add code with known

Re: [DISCUSSION] High-volume counters in Cassandra

The consensus in this thread seems to be moving towards the following todos in order to get 1072 into trunk. * create separate api methods for increments * mark functionality as experimental * further code cleanup (please comment on jira with specific suggestions) Is this a reasonable summary? W

Re: [DISCUSSION] High-volume counters in Cassandra

Yes. On Mon, Sep 6, 2010 at 12:11 PM, Johan Oskarsson wrote: > The consensus in this thread seems to be moving towards the following todos > in order to get 1072 into trunk. > > * create separate api methods for increments > * mark functionality as experimental > * further code cleanup (please c

Re: [DISCUSSION] High-volume counters in Cassandra

You're a fucking hero. On Sep 6, 2010 12:12 PM, "Johan Oskarsson" wrote: The consensus in this thread seems to be moving towards the following todos in order to get 1072 into trunk. * create separate api methods for increments * mark functionality as experimental * further code cleanup (please c

Re: [DISCUSSION] High-volume counters in Cassandra

Sorry, I hit reply thinking that was going to just Johan. My bad. It is true, though. On Mon, Sep 6, 2010 at 12:46 PM, Jeff Hodges wrote: > You're a fucking hero. > > On Sep 6, 2010 12:12 PM, "Johan Oskarsson" wrote: > The consensus in this thread seems to be moving towards the following todos >