cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10491) Inconsistent "position" numbering for keys in "system_schema.columns"
Date Fri, 09 Oct 2015 14:37:26 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950483#comment-14950483
] 

Sylvain Lebresne commented on CASSANDRA-10491:
----------------------------------------------

bq. What do you suggest doing instead? -1 there is a replacement for {{null}}.

Well, I have thinking 0. From a client perspective, for partition keys, the position means
the position in the partition key, so it _is_ inconsistent to have the first partition key
be 0 when there is 2 of them and -1 when there is only 1. Even internally, we used to use
{{null}} when there is a single partition key because internally the type is not a {{CompositeType}},
but it's more logical to have partition key always have a position (and so never {{ColumnDefinition.NO_POSITION}}),
the same way clustering columns always have one.

bq. The goal is to be able to let people have large numbers of columns (combined, in all of
their tables in all keyspaces) and still be able to have a low tombstone warning/error threshold.

I'm either completely missing something or you're thinking of changes I'm not suggesting,
cause I fail to see how using a 0 instead of -1 would impact tombstone warning thresholds.

> Inconsistent "position" numbering for keys in "system_schema.columns"
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-10491
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10491
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Michael Penick
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>              Labels: client-impacting
>
> A single component primary key starts off with a -1 position.
> {code}
> cqlsh> CREATE TABLE test.table1 (key1 text, value1 text, value2 text, PRIMARY KEY(key1));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM system_schema.columns
WHERE keyspace_name = 'test' and  table_name = 'table1' ;
>  keyspace_name | table_name | column_name | kind          | position
> ---------------+------------+-------------+---------------+----------
>           test |     table1 |        key1 | partition_key |       -1
>           test |     table1 |      value1 |       regular |       -1
>           test |     table1 |      value2 |       regular |       -1
> {code}
> A single component clustering key starts off with a 0 position.
> {code}
> cqlsh> CREATE TABLE test.table2 (key1 text, value1 text, value2 text, PRIMARY KEY(key1,
value1));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM system_schema.columns
WHERE keyspace_name = 'test' and  table_name = 'table2' ;
>  keyspace_name | table_name | column_name | kind          | position
> ---------------+------------+-------------+---------------+----------
>           test |     table2 |        key1 | partition_key |       -1
>           test |     table2 |      value1 |    clustering |        0
>           test |     table2 |      value2 |       regular |       -1
> {code}
> When another component is added to the primary key it starts at 0.
> {code}
> cqlsh> CREATE TABLE test.table3 (key1 text, value1 text, value2 text, PRIMARY KEY((key1,
value1)));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM system_schema.columns
WHERE keyspace_name = 'test' and  table_name = 'table3' ;
>  keyspace_name | table_name | column_name | kind          | position
> ---------------+------------+-------------+---------------+----------
>           test |     table3 |        key1 | partition_key |        0
>           test |     table3 |      value1 | partition_key |        1
>           test |     table3 |      value2 |       regular |       -1
> {code}
> which is the same as a multiple component clustering key.
> {code}
> cqlsh> CREATE TABLE test.table4 (key1 text, value1 text, value2 text, PRIMARY KEY(key1,
value1, value2));
> cqlsh> SELECT keyspace_name, table_name, column_name, kind, position FROM system_schema.columns
WHERE keyspace_name = 'test' and  table_name = 'table4' ;
>  keyspace_name | table_name | column_name | kind          | position
> ---------------+------------+-------------+---------------+----------
>           test |     table4 |        key1 | partition_key |       -1
>           test |     table4 |      value1 |    clustering |        0
>           test |     table4 |      value2 |    clustering |        1
> {code}
> Shouldn't a single component primary key start off with a position of 0?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message