You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Daniel Meyer (JIRA)" <ji...@apache.org> on 2013/09/19 18:56:59 UTC

[jira] [Comment Edited] (CASSANDRA-5732) Can not query secondary index

    [ https://issues.apache.org/jira/browse/CASSANDRA-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772032#comment-13772032 ] 

Daniel Meyer edited comment on CASSANDRA-5732 at 9/19/13 4:56 PM:
------------------------------------------------------------------

This is definitly a bug in latest 1.2.  Just reproduced in 1.2.10

Repro is easy.  Create single node cluster off of latest 1.2 branch and do the following:

cqlsh:ks> CREATE TABLE test ( row text, name text, PRIMARY KEY (row) );
cqlsh:ks> ALTER TABLE test WITH caching='all';
cqlsh:ks> INSERT INTO test (row, name) VALUES ( 'row1', 'daniel' );
cqlsh:ks> INSERT INTO test (row, name) VALUES ( 'row2', 'ryan' );
cqlsh:ks> CREATE INDEX on test (name);
cqlsh:ks> select * from test where name='daniel';

 row  | name
------+--------
 row1 | daniel
#Notice how row is returned

Stop node and set:
row_cache_size_in_mb: 200
Start node again and follow this procedure:

cqlsh> use ks;
cqlsh:ks> select * from test where name='daniel';
#Nothing is returned from this query


Now stop the node and set:
row_cache_size_in_mb: 0

start the node and do the following:

cqlsh> use ks;
cqlsh:ks> select * from test where name='daniel';

 row  | name
------+--------
 row1 | daniel

#Notice how the row is returned.
                
      was (Author: dmeyer):
    This is definitly a bug in latest 1.2.  Just reproduced in 1.2.10

Repro is easy.  Create single node cluster off of latest 1.2 branch and do the following:

cqlsh> use ks;
cqlsh:ks> CREATE TABLE test ( row text, name text, PRIMARY KEY (row) );
cqlsh:ks> ALTER TABLE test WITH caching='all';
cqlsh:ks> INSERT INTO test (row, name) VALUES ( 'row1', 'daniel' );
cqlsh:ks> INSERT INTO test (row, name) VALUES ( 'row2', 'ryan' );
cqlsh:ks> CREATE INDEX on test (name);
cqlsh:ks> select * from test where name='daniel';

 row  | name
------+--------
 row1 | daniel
#Notice how row is returned

Stop node and set:
row_cache_size_in_mb: 200
Start node again and follow this procedure:

cqlsh> use ks;
cqlsh:ks> select * from test where name='daniel';
#Nothing is returned from this query


Now stop the node and set:
row_cache_size_in_mb: 0

start the node and do the following:

cqlsh> use ks;
cqlsh:ks> select * from test where name='daniel';

 row  | name
------+--------
 row1 | daniel

#Notice how the row is returned.
                  
> Can not query secondary index
> -----------------------------
>
>                 Key: CASSANDRA-5732
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5732
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5
>         Environment: Windows 8, Jre 1.6.0_45 32-bit
>            Reporter: Tony Anecito
>            Assignee: Daniel Meyer
>
> Noticed after taking a column family that already existed and assigning to an IntegerType index_type:KEYS and the caching was already set to 'ALL' that the prepared statement do not return rows neither did it throw an exception. Here is the sequence.
> 1. Starting state query running with caching off for a Column Family with the query using the secondary index for te WHERE clause.
> 2, Set Column Family caching to ALL using Cassandra-CLI and update CQL. Cassandra-cli Describe shows column family caching set to ALL
> 3. Rerun query and it works.
> 4. Restart Cassandra and run query and no rows returned. Cassandra-cli Describe shows column family caching set to ALL
> 5. Set Column Family caching to NONE using Cassandra-cli and update CQL. Rerun query and no rows returned. Cassandra-cli Describe for column family shows caching set to NONE.
> 6. Restart Cassandra. Rerun query and it is working again. We are now back to the starting state.
> Best Regards,
> -Tony

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira