You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Kirk True (Jira)" <ji...@apache.org> on 2021/02/06 00:11:00 UTC
[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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org