From b4500a55c7ca1f08262d29ab03c0cb545f086df4 Mon Sep 17 00:00:00 2001 From: Konstantin Osipov Date: Tue, 15 Dec 2020 18:06:47 +0300 Subject: [PATCH] test: add a test case for list prepend/append with custom timestamp Scylla now takes a custom timestamp into account when executing list append/prepend operations. Test the new semantics. --- test/cql/list_test.cql | 51 +++++++++++++ test/cql/list_test.result | 146 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 197 insertions(+) diff --git a/test/cql/list_test.cql b/test/cql/list_test.cql index 181bf13fb8..ab05eec4fb 100644 --- a/test/cql/list_test.cql +++ b/test/cql/list_test.cql @@ -36,3 +36,54 @@ APPLY BATCH; SELECT l FROM t WHERE pk = 0; DROP TABLE t; +-- test custom timestamps +-- Scylla, unlike Cassandra, takes custom timestamps into account +-- in list append/prepend operations +CREATE TABLE t (pk INT PRIMARY KEY, l LIST); + +-- Even though it's an append, since the timestamp is in the past, +-- the result is going to be a prepend +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-4] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +-- using the same timestamp will reset the value to a new one, but only if +-- it is larger lexicographically +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-5] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-3] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +-- and what if we try two values at once? +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-5, -2] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +-- if a timestamp grows, the new value is after the previous one in the list +UPDATE t USING TIMESTAMP 1607100000000001 SET l = l + [-1] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +-- And if it goes back, it's prepended +UPDATE t USING TIMESTAMP 1607099999999999 SET l = l + [-4] WHERE pk = 0; +SELECT l FROM t WHERE pk = 0; +-- The batch has both list append and prepend. +-- The relative order of appends and prepends in the batch +-- is correct, but since batch timestamp is lower +-- than anything that is already in the list cell +-- all appends and prepends of the batch end up +-- preceding all previous values of the list. +BEGIN BATCH USING TIMESTAMP 1607099999999998 + UPDATE t SET l = [-5] + l WHERE pk = 0 + UPDATE t SET l = [-7, -6] + l WHERE pk = 0 + UPDATE t SET l = [-8] + l WHERE pk = 0 + UPDATE t SET l = l + [0] WHERE pk = 0 + UPDATE t SET l = l + [1, 2] WHERE pk = 0 + UPDATE t SET l = l + [3] WHERE pk = 0 +APPLY BATCH; +SELECT l FROM t WHERE pk = 0; +-- try a very low timestamp +BEGIN BATCH USING TIMESTAMP 1000 + UPDATE t SET l = [-8] + l WHERE pk = 0 + UPDATE t SET l = [-10, -9] + l WHERE pk = 0 + UPDATE t SET l = [-11] + l WHERE pk = 0 + UPDATE t SET l = l + [4] WHERE pk = 0 + UPDATE t SET l = l + [5, 6] WHERE pk = 0 + UPDATE t SET l = l + [7] WHERE pk = 0 +APPLY BATCH; +SELECT l FROM t WHERE pk = 0; + +DROP TABLE t; diff --git a/test/cql/list_test.result b/test/cql/list_test.result index 102cd7c954..50065cdabe 100644 --- a/test/cql/list_test.result +++ b/test/cql/list_test.result @@ -212,3 +212,149 @@ DROP TABLE t; { "status" : "ok" } +-- test custom timestamps +-- Scylla, unlike Cassandra, takes custom timestamps into account +-- in list append/prepend operations +CREATE TABLE t (pk INT PRIMARY KEY, l LIST); +{ + "status" : "ok" +} + +-- Even though it's an append, since the timestamp is in the past, +-- the result is going to be a prepend +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-4] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-4]" + } + ] +} +-- using the same timestamp will reset the value to a new one, but only if +-- it is larger lexicographically +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-5] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-4]" + } + ] +} +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-3] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-3]" + } + ] +} +-- and what if we try two values at once? +UPDATE t USING TIMESTAMP 1607100000000000 SET l = l + [-5, -2] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-3, -2]" + } + ] +} +-- if a timestamp grows, the new value is after the previous one in the list +UPDATE t USING TIMESTAMP 1607100000000001 SET l = l + [-1] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-3, -2, -1]" + } + ] +} +-- And if it goes back, it's prepended +UPDATE t USING TIMESTAMP 1607099999999999 SET l = l + [-4] WHERE pk = 0; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-4, -3, -2, -1]" + } + ] +} +-- The batch has both list append and prepend. +-- The relative order of appends and prepends in the batch +-- is correct, but since batch timestamp is lower +-- than anything that is already in the list cell +-- all appends and prepends of the batch end up +-- preceding all previous values of the list. +BEGIN BATCH USING TIMESTAMP 1607099999999998 + UPDATE t SET l = [-5] + l WHERE pk = 0 + UPDATE t SET l = [-7, -6] + l WHERE pk = 0 + UPDATE t SET l = [-8] + l WHERE pk = 0 + UPDATE t SET l = l + [0] WHERE pk = 0 + UPDATE t SET l = l + [1, 2] WHERE pk = 0 + UPDATE t SET l = l + [3] WHERE pk = 0 +APPLY BATCH; +{ + "status" : "ok" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-8, -7, -6, -5, 0, 1, 2, 3, -4, -3, -2, -1]" + } + ] +} +-- try a very low timestamp +BEGIN BATCH USING TIMESTAMP 1000 + UPDATE t SET l = [-8] + l WHERE pk = 0 + UPDATE t SET l = [-10, -9] + l WHERE pk = 0 + UPDATE t SET l = [-11] + l WHERE pk = 0 + UPDATE t SET l = l + [4] WHERE pk = 0 + UPDATE t SET l = l + [5, 6] WHERE pk = 0 + UPDATE t SET l = l + [7] WHERE pk = 0 +APPLY BATCH; +{ + "message" : "exceptions::invalid_request_exception (List prepend custom timestamp must be greater than Jan 1 2010 00:00:00)", + "status" : "error" +} +SELECT l FROM t WHERE pk = 0; +{ + "rows" : + [ + { + "l" : "[-8, -7, -6, -5, 0, 1, 2, 3, -4, -3, -2, -1]" + } + ] +} + +DROP TABLE t; +{ + "status" : "ok" +}