[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132855#comment-14132855
]
Kirk True commented on CASSANDRA-4938:
--------------------------------------
Here are the naive options as I see it:
# No rows returned, i.e. leave existing behavior
# Return rows as they become available in the index
# Return error ('No indexed columns present') until index creation complete
# Block until index creation complete as requested by OP. But who blocks? Just
the creating client, all clients? Block for reads, writes, or?
I'm sure there are arguments to be made for each. The last option reminds me of
the oft-cited complaint about the pain around index creation in traditional
RDBMS implementations.
> CREATE INDEX can block for creation now that schema changes may be concurrent
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-4938
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4938
> Project: Cassandra
> Issue Type: Wish
> Reporter: Krzysztof Cieslinski Cognitum
> Assignee: Kirk True
> Priority: Minor
> Labels: lhf
> Fix For: 3.0
>
>
> Response from CREATE INDEX command comes faster than the creation of
> secondary index. So below code:
> {code:xml}
> CREATE INDEX ON tab(name);
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> doesn't return any rows(of course, in column family "tab", there are some
> records with "name" value = 'Chris'..) and any errors ( i would expect
> something like ??"Bad Request: No indexed columns present in by-columns
> clause with Equal operator"??)
> Inputing some timeout between those two commands resolves the problem, so:
> {code:xml}
> CREATE INDEX ON tab(name);
> Sleep(timeout); // for column family with 2000 rows the timeout had to be set
> for ~1 second
> SELECT * FROM tab WHERE name = 'Chris';
> {code}
> will return all rows with values as specified.
> I'm using single node cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
