Re: rounded timestamp ?

2012-07-11 Thread Sylvain Lebresne
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
 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
>
>
>
>


rounded timestamp ?

2012-07-11 Thread Marco Matarazzo
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