Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7A8C318C56 for ; Fri, 9 Oct 2015 08:02:32 +0000 (UTC) Received: (qmail 61988 invoked by uid 500); 9 Oct 2015 08:02:27 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 61952 invoked by uid 500); 9 Oct 2015 08:02:27 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 61938 invoked by uid 99); 9 Oct 2015 08:02:27 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Oct 2015 08:02:27 +0000 Date: Fri, 9 Oct 2015 08:02:27 +0000 (UTC) From: "Sylvain Lebresne (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-10491) Inconsistent "position" numbering for keys in "system_schema.columns" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-10491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950051#comment-14950051 ] Sylvain Lebresne commented on CASSANDRA-10491: ---------------------------------------------- I tend to agree, there is no particular reason not to use 0 in that case. More generally, I think we should never use {{ColumnDefinition.NO_POSITION}} for partition keys internally as we don't really need it and it doesn't make much sense (it only make sense from a historical point of view but that's not a good enough reason to keep it imo). > 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)