[jira] [Commented] (CASSANDRA-7487) Create index does not reject duplicate index name on tables with the same name but different keyspace

["Philip Thompson (JIRA)" <ji...@apache.org>]

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

Philip Thompson commented on CASSANDRA-7487:
--------------------------------------------

I may be misunderstanding your description, but what exactly is the issue? It seems like you want there to be no name collision of indices even across keyspaces, but it doesn't look like you described any actual bugs resulting from the current implementation. If you did and I missed it, I apologize.

> 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)