7f17894c88
In the past, DESC SCHEMA would produce create statements for both the base and the log table. That was incorrect as the log table is automatically created alongside the base one. That was solved in scylladb/scylladb@9ab57b1 (scylladb/scylladb#18467). The mentioned changes implemented the following solution: * DESC SCHEMA/KEYSPACE/TABLE would still print a create statement for the CDC base table, * DESC SCHEMA/KEYSPACE would start printing an alter statement for the CDC log table. That statement would ensure that the restored log table has the same parameters as the original one, * DESC TABLE <base table> would behave as DESC SCHEMA/KEYSPACE, i.e. it would print a create statement for the base table and an alter statement for the log table, * DESC TABLE <log table> would result in an error. While that solution was good and behaved correctly in the context of restoring the schema, it had one flaw: describe statement aren't only used as a means for producing a backup; they also serve an informative purpose to learn about the schema, e.g. to learn what parameters a specific table uses. Because we didn't allow for describing CDC log tables, the user couldn't look them up directly via a describe statement -- they had to describe the base table for that. Attempting to describe a log table ended with an error, e.g.: ``` $ DESC TABLE ks.t_scylla_cdc_log; ks.t_scylla_cdc_log is a cdc log table and it cannot be described directly. Try `DESC TABLE ks.t` to describe cdc base table and it's log table. ``` In these changes, we allow for describing CDC log tables again. The semantics of the first three bullets above remains unchanged, but we impose new behavior for DESC TABLE <log table>: * When the user executes DESC TABLE <log table>, a create statement will be returned, treating the table as if it were a regular one, * The create statement will be wrapped in CQL comment markers. The rationale for the second bullet is that although we want to give the user a means to look into the structure and options of a CDC log table, the returned statement is not supposed to be ever executed by them. We want to minimize the risk of that. An example of the behavior after the change: ``` $ DESC TABLE ks.t_scylla_cdc_log; /* Do NOT execute this statement! It's only for informational purposes. A CDC log table is created automatically when the base is created. CREATE TABLE ks.t_scylla_cdc_log ( "cdc$stream_id" blob, "cdc$time" timeuuid, "cdc$batch_seq_no" int, "cdc$end_of_batch" boolean, "cdc$operation" tinyint, "cdc$ttl" bigint, p int, PRIMARY KEY ("cdc$stream_id", "cdc$time", "cdc$batch_seq_no") ) WITH CLUSTERING ORDER BY ("cdc$time" ASC, "cdc$batch_seq_no" ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'enabled': 'false', 'keys': 'NONE', 'rows_per_partition': 'NONE'} AND comment = 'CDC log for ks.t' AND compaction = {'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': '60', 'compaction_window_unit': 'MINUTES', 'expired_sstable_check_frequency_seconds': '1800'} AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1 AND default_time_to_live = 0 AND gc_grace_seconds = 0 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND speculative_retry = '99.0PERCENTILE'; */ ``` We also extend the developer documentation regarding DESCRIBE statements on CDC tables. Fixes scylladb/scylladb#21235 Backport: these changes are an enhancement, so not needed. Closes scylladb/scylladb#21228 * github.com:scylladb/scylladb: docs/dev: Document semantics of describing CDC tables cql3: Allow for describing CDC log tables
Scylla in-source tests.
For details on how to run the tests, see docs/dev/testing.md
Shared C++ utils, libraries are in lib/, for Python - pylib/
alternator - Python tests which connect to a single server and use the DynamoDB API unit, boost, raft - unit tests in C++ cql-pytest - Python tests which connect to a single server and use CQL topology* - tests that set up clusters and add/remove nodes cql - approval tests that use CQL and pre-recorded output rest_api - tests for Scylla REST API Port 9000 scylla-gdb - tests for scylla-gdb.py helper script nodetool - tests for C++ implementation of nodetool
If you can use an existing folder, consider adding your test to it. New folders should be used for new large categories/subsystems, or when the test environment is significantly different from some existing suite, e.g. you plan to start scylladb with different configuration, and you intend to add many tests and would like them to reuse an existing Scylla cluster (clusters can be reused for tests within the same folder).
To add a new folder, create a new directory, and then
copy & edit its suite.ini.