[
https://issues.apache.org/jira/browse/CASSANDRA-8505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022173#comment-15022173
]
Sam Tunnicliffe commented on CASSANDRA-8505:
--------------------------------------------
Looks pretty good to me, I just have a small nit & one question/suggestion
about naming:
Firstly, the catch blocks for {{TombstoneOverwhelmingException}} and
{{IndexNotAvailableException}} in {{MessageDeliveryTask::run}} can be combined
into one multi catch. Also, that catch for {{IndexNotAvailableException}} was
only added in 3.0, and it seems it could also be done for the 2.2 branch.
On the question of naming, I wonder if perhaps the names of the new methods
which check the state of the indexes ought to reflect the fact that the
readiness is in regard to querying (i.e. an index will process updates as soon
as it's created, the new flag just guards against it's use in queries). So, on
the 2.2 branch, we could rename {{SI::isReady}} to {{SI::isQueryable}} and on
3.0 {{SIM::isIndexReady}} -> {{SIM::isIndexQueryable}}.
Do you have any thoughts on that?
> Invalid results are returned while secondary index are being build
> ------------------------------------------------------------------
>
> Key: CASSANDRA-8505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8505
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Reporter: Benjamin Lerer
> Assignee: Benjamin Lerer
> Fix For: 2.2.x, 3.0.x
>
>
> If you request an index creation and then execute a query that use the index
> the results returned might be invalid until the index is fully build. This is
> caused by the fact that the table column will be marked as indexed before the
> index is ready.
> The following unit tests can be use to reproduce the problem:
> {code}
> @Test
> public void testIndexCreatedAfterInsert() throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, primary key((a,
> b)))");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 0, 0);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 1, 1);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 2, 2);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 0, 3);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 1, 4);");
>
> createIndex("CREATE INDEX ON %s(b)");
>
> assertRows(execute("SELECT * FROM %s WHERE b = ?;", 1),
> row(0, 1, 1),
> row(1, 1, 4));
> }
>
> @Test
> public void testIndexCreatedBeforeInsert() throws Throwable
> {
> createTable("CREATE TABLE %s (a int, b int, c int, primary key((a,
> b)))");
> createIndex("CREATE INDEX ON %s(b)");
>
> execute("INSERT INTO %s (a, b, c) VALUES (0, 0, 0);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 1, 1);");
> execute("INSERT INTO %s (a, b, c) VALUES (0, 2, 2);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 0, 3);");
> execute("INSERT INTO %s (a, b, c) VALUES (1, 1, 4);");
> assertRows(execute("SELECT * FROM %s WHERE b = ?;", 1),
> row(0, 1, 1),
> row(1, 1, 4));
> }
> {code}
> The first test will fail while the second will work.
> In my opinion the first test should reject the request as invalid (as if the
> index was not existing) until the index is fully build.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
