I've updated the DataModel page on the wiki to reflect this discussion. http://wiki.apache.org/cassandra/DataModel ~Noah
On Sun, Mar 21, 2010 at 9:46 PM, Michael Pearson <mjpear...@gmail.com>wrote: > Just a note for PHP users that using microtimes with the > thrift_protocol module won't work on 32-bit machines > (https://issues.apache.org/jira/browse/THRIFT-729). > > .michael. > > On Sun, Mar 21, 2010 at 8:51 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > > Looks like consensus is that "microseconds since epoch" is the way to > > go. I've updated the cli to do this. (Will be in the release after > > 0.6 beta3.) > > > > -Jonathan > > > > On Thu, Mar 18, 2010 at 3:37 PM, Jeff Hodges <jhod...@twitter.com> > wrote: > >> 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 it in after the fact. > >> -- > >> Jeff > >> > >> On Thu, Mar 18, 2010 at 12:36 AM, Jonathan Hseu <vom...@vomjom.net> > wrote: > >>> Jonathan Ellis suggested that I bring this issue to the dev mailing > list: > >>> > >>> Cassandra should recommended a default timestamp across all clients > >>> libraries. > >>> > >>> Many users on IRC are having difficulty when using different clients > because > >>> different clients are using different timestamps. If you insert with > one > >>> client, you may not be able to modify the key later with another. The > >>> Cassandra website doesn't seem to mention timestamps much, so users get > >>> confused when operations fail on certain clients. > >>> > >>> Here's what different clients are using: > >>> > >>> 1. Cassandra CLI: Milliseconds since UTC epoch. > >>> 2. lazyboy: Seconds since UTC epoch. It used to be seconds since local > time > >>> epoch. Now it's changing again to microseconds since UTC epoch. > >>> 3. driftx's client: Milliseconds since UTC epoch. > >>> 4. The example app, Twissandra: Microseconds since UTC epoch. > >>> 5. pycassa: Microseconds since UTC epoch. It used to be seconds since > local > >>> time epoch. > >>> 6. The most popular Cassandra Ruby client: Microseconds since UTC > epoch. > >>> > >>> Here's why the default recommended timestamp should be microseconds > since > >>> UTC epoch: > >>> > >>> 1. It allows backwards-compatibility. Some people are already using > >>> microseconds, so if it suddenly switched to milliseconds, all the > timestamps > >>> would be smaller, and they'd be unable to insert or remove existing > columns. > >>> Microsecond timestamps would always be greater than millisecond > timestamps, > >>> so new operations would work. > >>> 2. There exist reasons people would want to use microseconds over > >>> milliseconds (finer granularity), but I don't think there are any > reasons > >>> one would prefer milliseconds over microseconds. > >>> > >>> 3 (just for me). I just changed pycassa to microseconds, and I'd hate > to > >>> change it again :( > >>> > >>> > >>> Jonathan Hseu > >>> > >> >
