[
https://issues.apache.org/jira/browse/CASSANDRA-14822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16794560#comment-16794560
]
Joseph Lynch edited comment on CASSANDRA-14822 at 3/18/19 3:43 PM:
-------------------------------------------------------------------
[~jrwest] thanks for taking a look. We could pursue an option where we patch
all drivers (at the minimum the in-tree python driver) to not output that
column, but I feel like this isn't really worth all the work that would take?
To achieve the goal of having the current Cassandra release be backwards
compatible with the previous version (server and client) we'd have to cut
releases of the pre 4.0 drivers as well.
Personally I think we should just WARN in 4.0 as suggested by [~iamaleksey]
[here|https://issues.apache.org/jira/browse/CASSANDRA-13910?focusedCommentId=16433077&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16433077],
and once we have a better process in place for deprecating/removing parts of
the public CQL user interface we could revisit it (or maybe server side
describe a la CASSANDRA-14825 or CASSANDRA-8005)? I'm not against throwing
exceptions on invalid input in general, but I'm not sure we evaluated the cost
to users of breaking them in this way as it's essentially free for us to ignore
and WARN in 4.0 and it's definitely not free for users to upgrade to new driver
versions.
At the very minimum we need to make it so that 4.0 can understand schemas that
were outputted by 4.0 itself. So I'll get that done regardless I guess.
was (Author: jolynch):
[~jrwest] thanks for taking a look. We could pursue an option where we patch
all drivers (at the minimum the in-tree python driver) to not output that
column, but I feel like this isn't really worth all the work that would take?
To achieve the goal of having the current Cassandra release be backwards
compatible with the previous version (server and client) we'd have to cut
releases of the pre 4.0 drivers as well.
Personally I think we should just WARN in 4.0 as suggested by [~iamaleksey]
here, and once we have a better process in place for deprecating/removing parts
of the public CQL user interface we could revisit it (or maybe server side
describe a la CASSANDRA-14825 or CASSANDRA-8005)? I'm not against throwing
exceptions on invalid input in general, but I'm not sure we evaluated the cost
to users of breaking them in this way as it's essentially free for us to ignore
and WARN in 4.0 and it's definitely not free for users to upgrade to new driver
versions.
At the very minimum we need to make it so that 4.0 can understand schemas that
were outputted by 4.0 itself. So I'll get that done regardless I guess.
> Cassandra 4.0 doesn't output DESCRIBE TABLE representations that are valid
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-14822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14822
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
> Reporter: Joseph Lynch
> Assignee: Joseph Lynch
> Priority: Low
> Labels: cqlsh
>
> Looks like right now on 4.0 the {{DESCRIBE}} output of a table is no longer
> valid since {{dclocal_read_repair_chance}} was removed:
> {noformat}
> cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.test (key text, value text, PRIMARY KEY(key));
> cqlsh> DESCRIBE TABLE test.test
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> value text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99p';
> {noformat}
> If you then try to copy and past that output it fails:
> {noformat}
> cqlsh> CREATE TABLE test.test2 (
> ... key text PRIMARY KEY,
> ... value text
> ... ) WITH bloom_filter_fp_chance = 0.01
> ... AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> ... AND comment = ''
> ... AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> ... AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> ... AND crc_check_chance = 1.0
> ... AND dclocal_read_repair_chance = 0.0
> ... AND default_time_to_live = 0
> ... AND gc_grace_seconds = 864000
> ... AND max_index_interval = 2048
> ... AND memtable_flush_period_in_ms = 0
> ... AND min_index_interval = 128
> ... AND read_repair_chance = 0.0
> ... AND speculative_retry = '99p';
> SyntaxException: Unknown property 'dclocal_read_repair_chance'
> {noformat}
> Currently we leave in {{dclocal_read_repair_chance}} and
> {{read_repair_chance}} for the drivers per the comments left during
> CASSANDRA-13910.
> I think we can just ignore those parameters in the validation/creation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
