incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Silas <n...@mahalo.com>
Subject Re: Standardizing Timestamps Across Clients
Date Tue, 23 Mar 2010 17:38:48 GMT
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 <mjpearson@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 <jbellis@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 <jhodges@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 <vomjom@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
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message