Server-side DESCRIBE should include scylladb-specific options

[bhalevy]

As a follow-up to #12381 that included table's tombstone_gc_options in the log message printed when the table is created,
those options should also be included when printing the table's schema as part of server-side DESCRIBE (via CQL or when dumping schema.cql when taking a snapshot).

[bhalevy]

Looking at an example schema.cql, it doesn't include other scylladb-specific options like the cdc options.

bhalevy@lt tmp$ cat /tmp/scylla-2661692/data/system/local-7ad54392bcdd35a684174e047860b377/snapshots/test/schema.cql 
CREATE TABLE system.local (
    key text,
    bootstrapped text,
    broadcast_address inet,
    cluster_name text,
    cql_version text,
    data_center text,
    gossip_generation int,
    host_id uuid,
    listen_address inet,
    native_protocol_version text,
    partitioner text,
    rack text,
    release_version text,
    rpc_address inet,
    schema_version uuid,
    supported_features text,
    thrift_version text,
    tokens set<text>,
    truncated_at map<uuid, blob>,
    PRIMARY KEY (key)
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL','rows_per_partition': 'ALL'}
    AND comment = 'information about the local node'
    AND compaction = {'class': 'SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1
    AND dclocal_read_repair_chance = 0
    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 read_repair_chance = 0
    AND speculative_retry = '99.0PERCENTILE';

[bhalevy]

@Jadw1 I believe you're worked in this area not long ago (e6ffc22)
Can you please look into this?

[Jadw1]

I can add this but it won't take affect (eg. in cqlsh) because of #12272. To increase the version, other changes need to be made to be compatible with Cassandra v4 (at least at driver level).

I wrote an email to our rnd-internal mailing list ("Increasing Scylla version to 4.x") but I don't know if any issues on that were scheduled.

[bhalevy]

Regardless of cqlsh support we use the server-side describe logic for generating the schema.cql file for snapshots.
And that one should be used for restore.

[Jadw1]

Could you provide me a specification how exactly the table's schema should look like?

[bhalevy]

There is no formal specification .
It is a file containing CQL statements to restore the table's schema at the time when the snapshot was taken.
We also use for the scylla sstable tools for building a schema in memory used for interpreting the sstables, but for that, I guess the scylla schema extensions are less important (but I'm not 100% sure about that).

[bhalevy]

See

scylladb/replica/table.cc

Lines 1538 to 1541 in 1bfe234

	future<> table::write_schema_as_cql(database& db, sstring dir) const {
	std::ostringstream ss;
	this->schema()->describe(db, ss, false);

[denesb]

Doesn't apply cleanly to 5.2, @Jadw1 please provide a backport PR.

[mykaul]

@Jadw1 - ping