Not really, I've passed on the comments to the doc teams. The column timestamp is just a 64 bit int like I said.
Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 29/04/2013, at 10:06 AM, Michael Theroux <mthero...@yahoo.com> wrote: > Yes, that does help, > > So, in the link I provided: > > http://www.datastax.com/docs/1.0/references/cql/UPDATE > > It states: > > You can specify these options: > > • Consistency level > • Time-to-live (TTL) > • Timestamp for the written columns. > > Where timestamp is a link to "Working with dates and times" and mentions the > 64bit millisecond value. Is that incorrect? > > -Mike > > On Apr 28, 2013, at 11:42 AM, Michael Theroux 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 >> >> >
