Hi,
I was wondering if there are any possible problems we may face if we use
completely fabricated values as TIMESTAMP when doing INSERTs and
UPDATEs. Because I can imagine a couple of examples where exploiting
column timestamps could simplify things.
Because Cassandra is LWW (last write wins) it's easy to store the
"latest value". Using a lightweight transaction you can also store the
"first value". However what if you don't want to use lightweight
transactions on every update or at all?
You could solve it making two simple inserts in a batch:
START BATCH
INSERT INTO table (id, latestValue) VALUES (:id, :value) USING TIMESTAMP
:change_timestamp;
INSERT INTO table (id, firstValue) VALUES (:id, :value) USING TIMESTAMP
:fabricated_timestamp;
APPLY BATCH;
where fabricated_timestamp is a value where you ensure that the higher
the change_timestamp the lower the fabricated_timestamp. And using
exactly the same approach you could store highest and lowest values
(which is not easy otherwise).
I understand that SELECT WRITETIME(firstValue) FROM table would return a
complete nonsense (theoretically anything from 01-01-1970 to whatever is
Long.MAX_VALUE) and that we can shoot ourselves in the foot if we screw
up the algorithm that generates "timestamps" but that's something we are
OK with.
What I'd like to know is if we could cause any problems to Cassandra
internals using fabricated values as column timestamps. I tried to
google but found only a mention that "it's possible but not recommended"
in an article 4 years old.
Thanks!
Andrew
