As the dude that worked on the 1016 prototype, I agree with this.
On Fri, Feb 11, 2011 at 10:53 AM, Stu Hood wrote:
> Honestly, I think we should just mark 1016 a dupe and move forward with
> 1311: we won't be hurting anyone's feelings, and the implementation from
> 1016 is: 1. much, much less co
I think I can help answer that. Avro would be nice because a) it's
going to be part of the core infrastructure of Hadoop and Hadoop is
how most of our long-term stored data is accessed and b) the schema
model is really nice (both keeping the schema in the file with the
serialized data and having a
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
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
+1
--
Jeff
On Tue, Apr 13, 2010 at 7:08 AM, Eric Evans wrote:
> On Tue, 2010-04-13 at 08:44 -0500, Gary Dusbabek wrote:
>> 2010/4/13 Ted Zlatanov :
>> > Should the functionality be exposed only through JMX, through nodetool,
>> > or through cassandra-cli? I'll create the ticket if you like and t
As one of the committers to cassandra.gem, microseconds is the way to
go. Specificity is nice to have when you haven't been thinking about
timestamps and suddenly have a deep, abiding need to care about them.
I cannot understate that. It is much easier to remove the specificity
than it is to put i
Dude, you were already subscribed. Stop.
--
Jeff
On Sat, Mar 13, 2010 at 7:00 PM, Ruiheng Wang（王瑞珩） wrote:
> 3ks
>
> --
> .★
> .*★*.* ★
> * .’
> ‘* .
> ‘ . ．
>
