Eric Wolak created CASSANDRA-13819: -------------------------------------- Summary: Surprising under-documented behavior with DELETE...USING TIMESTAMP Key: CASSANDRA-13819 URL: https://issues.apache.org/jira/browse/CASSANDRA-13819 Project: Cassandra Issue Type: Bug Reporter: Eric Wolak Priority: Minor
While investigating differences between various Bigtable derivatives, I‘ve run into an odd behavior of Cassandra. I’m guessing this is intended behavior, but it's surprising enough to me that I think it should be explicitly documented. Let‘s say I have a sensor device reporting data with timestamps. It has a great clock, so I use its timestamps in a USING TIMESTAMP clause in my INSERT statements. One day Jeff realizes that we had a hardware bug with the sensor, and data before timestamp T is incorrect. He issues a DELETE...USING TIMESTAMP T to remove the old data. In the meantime, Sam figures out a way to backfill the data, and she writes a job to insert corrected data into the same table. In keeping with the schema, her job issues INSERT...USING TIMESTAMP statememts, with timestamps before T (because that’s the time the data points correspond to). When testing her job, Sam discovers that the backfilled data isn‘t appearing in the database! In fact, there’s no way for her to insert data with a TIMESTAMP <= T, because the tombstone written by Jeff several days ago is masking them. How can Sam backfill the corrected data? This behavior seems to match the HBase “Current Limitation” that Deletes Mask Puts, documented at http://hbase.apache.org/book.html#_deletes_mask_puts. Should the Cassandra docs also explicitly call-out this behavior? Related: http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org