A standard default would be nice, but while we're making
recommendations I'd also suggest that client libs should make this
parameter easy to override. Client apps can do lots of interesting
things by setting timestamps explicitly. You can get a sort of quasi-
transaction by using the same timestamp for a set of operations, for
example.
Mike
On Mar 18, 2010, at 1:11 PM, Ben Standefer <benstande...@gmail.com>
wrote:
+1 I think this is a great idea. I've been bitten by this when
switching
clients, and it took a while to figure out what was going on. Good
job on
pycassa, vomjom!
-Ben
2010/3/18 Ted Zlatanov <t...@lifelogs.com>
On Thu, 18 Mar 2010 02:36:35 -0500 Jonathan Hseu <vom...@vomjom.net>
wrote:
JH> Jonathan Ellis suggested that I bring this issue to the dev
mailing
list:
JH> Cassandra should recommended a default timestamp across all
clients
JH> libraries.
...
JH> Here's what different clients are using:
JH> 1. Cassandra CLI: Milliseconds since UTC epoch.
JH> 2. lazyboy: Seconds since UTC epoch. It used to be seconds
since local
time
JH> epoch. Now it's changing again to microseconds since UTC epoch.
JH> 3. driftx's client: Milliseconds since UTC epoch.
JH> 4. The example app, Twissandra: Microseconds since UTC epoch.
JH> 5. pycassa: Microseconds since UTC epoch. It used to be
seconds since
local
JH> time epoch.
JH> 6. The most popular Cassandra Ruby client: Microseconds since UTC
epoch.
It's good to standardize :)
In Perl land, Net::Cassandra::Easy is using seconds but should be
using
microseconds. I'll change it for 0.4 (the underlying Thrift code
will
DTRT for the 64-bit encoding using Bit::Vector). Net::Cassandra uses
seconds and should also be changed; CC-d to that module's maintainer.
Ted
