incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <aa...@thelastpickle.com>
Subject Re: CQL Clarification
Date Sun, 28 Apr 2013 21:42:16 GMT
I think this is some confusion about the two different usages of timestamp. 

The timestamp stored with the column value (not a column of timestamp type) is stored using
microsecond scale, it's just a 64 bit int we do not use it as a time value. Each mutation
in a single request will have a different timestamp as per https://github.com/apache/cassandra/blob/cassandra-1.2/src/java/org/apache/cassandra/service/QueryState.java#L48


A column of type timestamp is internally stored as a DateTime type which is milliseconds past
the epoch https://github.com/apache/cassandra/blob/cassandra-1.2/src/java/org/apache/cassandra/db/marshal/DateType.java

Does that help ? 

-----------------
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 29/04/2013, at 3:42 AM, Michael Theroux <mtheroux2@yahoo.com> wrote:

> Hello,
> 
> Just wondering if I can get a quick clarification on some simple CQL.  We utilize Thrift
CQL Queries to access our cassandra setup.  As clarified in a previous question I had, when
using CQL and Thrift, timestamps on the cassandra column data is assigned by the server, not
the client, unless "AND TIMESTAMP" is utilized in the query, for example:
> 
> http://www.datastax.com/docs/1.0/references/cql/UPDATE
> 
> According to the Datastax documentation, this timestamp should be:
> 
> "Values serialized with the timestamp type are encoded as 64-bit signed integers representing
a number of milliseconds since the standard base time known as the epoch: January 1 1970 at
00:00:00 GMT."
> 
> However, my testing showed that updates didn't work when I used a timestamp of this format.
 Looking at the Cassandra code, it appears that cassandra will assign a timestamp of System.currentTimeMillis()
* 1000 when a timestamp is not specified, which would be the number of nanoseconds since the
stand base time.  In my test environment, setting the timestamp to be the current time * 1000
seems to work.  It seems that if you have an older installation without TIMESTAMP being specified
in the CQL,   or a mixed environment, the timestamp should be * 1000.
> 
> Just making sure I'm reading everything properly... improperly setting the timestamp
could cause us some serious damage.
> 
> Thanks,
> -Mike
> 
> 


Mime
View raw message