cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-7487) Create index does not reject duplicate index name on tables with the same name but different keyspace
Date Sat, 20 Sep 2014 03:47:33 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brandon Williams resolved CASSANDRA-7487.
-----------------------------------------
    Resolution: Invalid

Indexes are just regular tables in the end.  You can't have two tables with the same name
in the same keyspace, but multiple keyspaces can.

> Create index does not reject duplicate index name on tables with the same name but different
keyspace
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7487
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7487
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: dan jatnieks
>            Priority: Minor
>
> Came across this while experimenting with how index names are managed.
> Create index tries to manage index names globally - even though indexes are maintained
per keyspace (table?) - and attempts to create indexes with the same name are generally rejected.
> However, given two tables with the same name in different keyspaces, it's possible to
create an index of the same name on each of those tables. 
> Here's the scenario:
> {noformat}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
'1'};
> cqlsh> CREATE KEYSPACE ks2 WITH replication = {'class': 'SimpleStrategy', 'replication_factor':
'1'};
> cqlsh> CREATE TABLE ks1.t1 (c1 int PRIMARY KEY, c2 int );
> cqlsh> CREATE TABLE ks1.t2 (c1 int PRIMARY KEY, c2 int );
> cqlsh> CREATE TABLE ks2.t1 (c1 int PRIMARY KEY, c2 int );
> // First index okay
> cqlsh> create index t_idx on ks1.t1 (c2) ;
> // Duplicate index on different table rejected - ok
> cqlsh> create index t_idx on ks1.t2 (c2) ;
> <ErrorMessage code=2300 [Query invalid because of configuration issue] message="Duplicate
index name t_idx">
> // Duplicate index on a different table in another keyspace rejected - ok
> cqlsh> create index t_idx on ks2.t2 (c2) ;
> <ErrorMessage code=2300 [Query invalid because of configuration issue] message="Duplicate
index name t_idx">
> // Duplicate index name in another keyspace works - wrong?
> cqlsh> create index t_idx on ks2.t1 (c2) ;
> {noformat}
> Describing keyspaces ks1 and ks2 shows that the table t1 in each has an index named t_idx,
so two indexes were created. Also dropping one of the indexes does not affect the other.
> {{CFMetaData.validate()}} calls {{existingIndexNames(cfName)}} to get all the known index
names, but filters out indexes for the current table.
> However, using only the {{cfName}}, this masks indexes that may exist on tables of the
same name in another keyspace. The keyspace is needed to properly filter index names for the
table.
> Issue CASSANDRA-7314 is related as it adds an optional {{keyspace}} argument to {{DROP
INDEX}}.
> So it seems that {{CREATE INDEX}} should either:
> - not scope index names globally, but rather by keyspace, or
> - continue to mamaging index names globally by rejecting the duplicate index name created
in the above scenario.



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

Mime
View raw message