cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8505) Invalid results are returned while secondary index are being build
Date Mon, 23 Nov 2015 14:42:11 GMT

    [ 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)

Mime
View raw message