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
