When using client supplied timestamps you need to ensure the clock on the client is in sync with the nodes in the cluster otherwise behaviour will be unpredictable.
On Thu, 18 Feb 2016 at 08:50 Tyler Hobbs <ty...@datastax.com> wrote: > 2016-02-18 2:00 GMT-06:00 Matthias Niehoff < > matthias.nieh...@codecentric.de>: > >> >> * is the 'using timestamp' feature (and providing statement timestamps) >> sufficiently robust and mature to build an application on? >> > > Yes. It's been there since the start of CQL3. > > >> * In a BatchedStatement, can different statements have different >> (explicitly provided) timestamps, or is the BatchedStatement's timestamp >> used for them all? Is this specified / stable behaviour? >> > > Yes, you can separate timestamps per statement. And, in fact, if you > potentially mix inserts and deletes on the same rows, you *should *use > explicit timestamps with different values. See the timestamp notes here: > http://cassandra.apache.org/doc/cql3/CQL.html#batchStmt > > >> * cqhsh reports a syntax error when I use 'using timestamp' with an >> update statement (works with 'insert'). Is there a good reason for this, or >> is it a bug? >> > > The "USING TIMESTAMP" goes in a different place in update statements. It > should be something like: > > UPDATE mytable USING TIMESTAMP ? SET col = ? WHERE key = ? > > > -- > Tyler Hobbs > DataStax <http://datastax.com/> > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Managed Cassandra / Spark on AWS, Azure and Softlayer
