[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17562470#comment-17562470
]
Benjamin Lerer commented on CASSANDRA-4938:
---
Improving the message make sense to me.
Adding new error codes comes with a certain amount of issues. It is not
possible to only change the error message?
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280046#comment-17280046
]
Kirk True commented on CASSANDRA-4938:
--
After some fumbling around in {{StorageProxy}} and {{RequestFailureReason}}, I
was able to get the server to send back a response so that {{cqlsh}} now sees
this:
{noformat}
Error from server: code=1300 [Replica(s) failed to execute read]
message="Operation failed - received 0 responses and 1 failures:
INDEX_NOT_AVAILABLE from localhost/127.0.0.1:7000" info={'failures': 1,
'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}
{noformat}
Thus the failure is listed as {{INDEX_NOT_AVAILABLE}} instead of {{UNKNOWN}}.
In my opinion, the message is still a little unclear. I could imagine making
the message a little more user-friendly:
{noformat}
The secondary index 'test_table_user_name_idx' is not yet available. Please
check (nodetool?) to determine its completion status or wait and try the query
again later.
{noformat}
Is it worth the effort to make the error better?
In terms of {{cqlsh}}, in {{protocol.py}}, there appear to be dedicated Python
classes for different types of responses, each with its own unique error code.
I would imagine adding a new class/code here would cause some changes needed
elsewhere?
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251697#comment-17251697
]
Benjamin Lerer commented on CASSANDRA-4938:
---
To be honest, the 4. solution is probably NOT a {{lhf}}.
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251689#comment-17251689
]
Benjamin Lerer commented on CASSANDRA-4938:
---
[~kirktrue] The exception thrown is the result of CASSANDRA-8505 which
correspond to the choice number 3. that you originally proposed.
{quote}
1. No rows returned, i.e. leave existing behavior
2. Return rows as they become available in the index
3. Return error ('No indexed columns present') until index creation complete
4. Block until index creation complete as requested by OP. But who blocks? Just
the creating client, all clients? Block for reads, writes, or?
{quote}
Even if {{4.}} is implemented in the way suggested by [~jbellis] you will need
that safety net in case somebody queries the index from another client
application.
As explained by [~slebresne] implementing {{4.}} is not a simple thing to do
and I am not sure it is worth the effort.
[~maxwellguo] The index is effectively local but most of the clients (including
nodetool) connect to only a single node and by consequence do not have a full
view of the cluster. An index can be built on one node but not on another one.
Even if we succeed to check all the nodes that are alive, we would have to
check what happen if a node was down at the time where the {{CREATE INDEX}} was
fired and is restarted after the index of the others has been built. My guess
is that the node will accept queries before its index is build therefore
failing the query but I did not check.
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251458#comment-17251458
]
maxwellguo commented on CASSANDRA-4938:
---
I think we can also add a nodetool to show the progress of the 2idx 's building
. for our index is local index.
IF it is ok ,I would like to open a issue . [~slebresne] [~brandon.williams]
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251422#comment-17251422
]
Kirk True commented on CASSANDRA-4938:
--
When trying to query against the table using the index before it's fully
created, I see this error on the server:
{noformat}
java.lang.RuntimeException:
org.apache.cassandra.index.IndexNotAvailableException: The secondary index
'test_table_user_name_idx' is not yet available
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2729)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.cassandra.index.IndexNotAvailableException: The secondary
index 'test_table_user_name_idx' is not yet available
at
org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:445)
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2011)
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2725)
... 6 common frames omitted
{noformat}
and this in `cqlsh`:
{noformat}
ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
localhost/127.0.0.1:7000" info={'failures': 1, 'received_responses': 0,
'required_responses': 1, 'consistency': 'ONE'}
{noformat}
It looks like the schema update event is fired on the _start_ of the index
creation, not on its _completion_.
> 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: Improvement
> Components: Feature/2i Index
>Reporter: Krzysztof Cieslinski Cognitum
>Assignee: Kirk True
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528626#comment-14528626
]
Jonathan Ellis commented on CASSANDRA-4938:
---
Okay, so we have some code to write for the event-pushing node to collate the
information from the cluster, but I think that's the right approach.
> 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.x
>
>
> 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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528106#comment-14528106
]
Sylvain Lebresne commented on CASSANDRA-4938:
-
bq. Can we push a "index build finished" event?
We definitively can add such new event and that's a fine idea. The one
difficulty might be however that ideally we'd want to notify once the index has
been built on all (alive) nodes, otherwise people will still get the
notification, query, and not get what they expect. But we also want all nodes
to be able to generate such notification (since a client generally register for
events only against one node). Which imply non trivial synchronization and
propagation of the end of index builds.
> 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.x
>
>
> 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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527867#comment-14527867
]
Jonathan Ellis commented on CASSANDRA-4938:
---
We push schema events to clients, right? Can we push a "index build finished"
event? I'd rather do that than block.
Related: cqlsh should show a message to users when schema events are pushed to
it.
> 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.x
>
>
> 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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527583#comment-14527583
]
Kirk True commented on CASSANDRA-4938:
--
Any updates on this?
> 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.x
>
>
> 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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132846#comment-14132846
]
Brandon Williams commented on CASSANDRA-4938:
-
I don't think blocking is the right solution either, but I guess if it's just
for cqlsh it might not be too bad of an idea. For Real Work it can still be
asynchronous and people can check compactionstats.
> 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)
[jira] [Commented] (CASSANDRA-4938) CREATE INDEX can block for creation now that schema changes may be concurrent
[
https://issues.apache.org/jira/browse/CASSANDRA-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995427#comment-13995427
]
Jeremiah Jordan commented on CASSANDRA-4938:
Do we really want to block on the asynchronous index creation? I agree it
would be nice to know when it is done, but I don't think blocking on the cql
command by default is the right way to go. Index creation could take hours.
> 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
>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.2#6252)
