[
https://issues.apache.org/jira/browse/CASSANDRA-19965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-19965:
----------------------------------------
Status: Changes Suggested (was: Review In Progress)
The patch looks generally good to me, but I did find a few issues.
{code:java}
cqlsh> CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'};
cqlsh> CREATE TABLE ks.t1 ( a int PRIMARY KEY, b int, c text, d int);
cqlsh> CREATE CUSTOM INDEX t1_b_idx ON ks.t1 (b) USING 'sai';
cqlsh> CREATE CUSTOM INDEX t1_c_idx ON ks.t1 (c) USING
'org.apache.cassandra.index.sai.StorageAttachedIndex';
cqlsh> CREATE CUSTOM INDEX t1_d_idx ON ks.t1 (d) USING 'storageattachedindex';
cqlsh> CREATE TABLE ks.t2 LIKE ks.t1 WITH ALL INDEXES;
Warnings :
Source table ks.t1 to copy indexes from to ks.t2 has custom indexes. These
indexes were not copied: [t1_c_idx, t1_d_idx]
{code}
To fix this I think you need to improve the check in
{{CopyTableStatement.maybeCopyIndexes}} so that it behaves a bit more like
{{IndexMetadata.getIndexClassName()}}
----
{code:java}
cqlsh> CREATE TABLE ks.t3 LIKE ks.t1 WITH ALL indexes;
SyntaxException: Failed parsing statement: [CREATE TABLE ks.t3 LIKE ks.t1 WITH
ALL indexes;] reason: IllegalArgumentException No enum constant
org.apache.cassandra.cql3.statements.schema.CopyTableStatement.CreateLikeOption.indexes
{code}
This is a result of using a string literal {{tableLikeSingleOption}} (in
{{{}Parser.g{}}}).
In an earlier comment, you said:
{quote}As the system_schema.indexes stores the definitions of secondary
indexes, we cannot use INDEXES as a keyword.
{quote}
{{INDEXES}} can be a keyword, just like {{KEYSPACES}} and {{TABLES}} are. I
would make it so and have {{setLikeOption}} be strongly typed instead of taking
a string param. I wanted to check this was actually correct, so I've pushed a
commit which does this plus a little extra clean up
[here|https://github.com/beobal/cassandra/commit/4252a8d349fc573a8033dea90f66650215d9a619]
.
----
{code:java}
cqlsh> CREATE TABLE ks.t1 ( a int PRIMARY KEY, b int, c text, d int);
cqlsh> CREATE INDEX t1_b_idx1 ON ks.t1(b);
cqlsh> CREATE INDEX t1_b_idx2 ON ks.t1(b) USING 'sai';
cqlsh> CREATE TABLE ks.t2 LIKE ks.t1 WITH ALL INDEXES ;
NoHostAvailable: ('Unable to complete the operation against any hosts', {<Host:
127.0.0.1:9042 datacenter1>: <Error from server: code=0000 [Server error]
message="java.lang.IllegalArgumentException: Multiple entries with same key:
t2_b_idx=org.apache.cassandra.schema.IndexMetadata@66d69642[id=353859a7-c954-3ab2-98fa-74d986e443c8,name=t2_b_idx,kind=CUSTOM,options={class_name=sai,
target=b}] and
t2_b_idx=org.apache.cassandra.schema.IndexMetadata@53fd209d[id=353859a7-c954-3ab2-98fa-74d986e443c8,name=t2_b_idx,kind=COMPOSITES,options={target=b}]">})
{code}
Until now it has only been possible to create indexes one at a time, so it was
sufficient to just check existing keyspace metadata to ensure we don't have a
clash of index names, which is what
{{KeyspaceMetadata.findAvailableIndexName(String baseName)}} does. Here though,
we may be creating multiple indexes in one operation so we also have to ensure
that they all have unique names including when there is more than one index on
a single column.
> CREATE TABLE LIKE with INDEX/ TRIGGER /ALL option
> ---------------------------------------------------
>
> Key: CASSANDRA-19965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19965
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Cluster/Schema, CQL/Syntax
> Reporter: Maxwell Guo
> Assignee: Maxwell Guo
> Priority: Normal
> Fix For: 5.x
>
>
> no matter Copy table with indexes or triggers under same keyspace or
> differenet.
> The indexes and trigger name should be different from the source in case of
> conflict.
> we need to
> 1.Adding cql parser for ALL/INDEX/TRIGGER when doing create table like
> 2.Automatic completion of keywords(LIKE/ALL/INDEX/TRIGGER) and function hints
> (the source table and target table explain_completion when doing table copy)
> at the cqlsh level.
> in pylib/cqlshlib/cql3handling.py and the test in
> pylib/cqlshlib/test/test_cqlsh_completion.py.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]