incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
Subject Re: rounded timestamp ?
Date Wed, 11 Jul 2012 13:20:13 GMT
There is no rounding or correction whatsoever. It just happens that if
you don't give a timestamp in CQL, the timestamp is generated server
side using that Java System.currentTimeMillis() that only provide
milliseconds precision. If you provide your own timestamp however we
use it without doing anything with it.

--
Sylvain

On Wed, Jul 11, 2012 at 1:56 PM, Marco Matarazzo
<marco.matarazzo@hexkeep.com> wrote:
> Greetings.
>
> Running (CQL 3) queries like:
>
>    update users set admin = 1 where corporation_id = '7a55bc4c-84e7-479c-9ac6-43f7836705b5';
>
> … I see in logs a row like:
>
> StorageProxy.java (line 175) Mutations/ConsistencyLevel are [RowMutation(keyspace='goh_test',
key='37613535626334632d383465372d343739632d396163362d343366373833363730356235', modifications=[ColumnFamily(users
[admin:false:1@1342006844093000,])])]/ONE
>
> If I understand it correctly, that 1342006844093000 is the timestamp in microseconds,
getting rounded to milliseconds.
>
> If I modify queries in this way:
>
>    update users using timestamp 1342006844106123 set admin = 1 where corporation_id =
'7a55bc4c-84e7-479c-9ac6-43f7836705b5';
>
> … the log row becomes:
>
> StorageProxy.java (line 175) Mutations/ConsistencyLevel are [RowMutation(keyspace='goh_test',
key='37613535626334632d383465372d343739632d396163362d343366373833363730356235', modifications=[ColumnFamily(users
[admin:false:1@1342006844106123,])])]/ONE
>
> …and what I see is that the timestamp get through NOT rounded, with microseconds precision.
>
>
> We see this behavior using cqlsh, C++ thrift bindings and phpcassa. I guess they all
use thrift, and so the rounding happens there.
>
> One of the "problems" is that sometimes it gets rounded up, so it's in the future. But
that's just a side effect of rounding, and I can't understand why in the first place there
is a rounding. I guess that the second case is just Cassandra "correcting" the timestamp with
data found in the CQL, and maybe thrift is still sending a milliseconds-rounded timestamp,
but I still can't see a reason for thrift doing this.
>
> Could someone enlighten me a bit on this matter ?
>
> --
> Marco Matarazzo
> == Hex Keep ==
>
> "You can learn more about a man
>   in one hour of play
>   than in one year of conversation.” - Plato
>
>
>
>

Mime
View raw message