Cassandra
  1. Cassandra
  2. CASSANDRA-3505

Explicitly requested keys will always be present in resultset

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.

      cqlsh> CREATE KEYSPACE ks1 with 
         ...   strategy_class =  
         ...     'org.apache.cassandra.locator.SimpleStrategy' 
         ...   and strategy_options:replication_factor=1;
        
      cqlsh> use ks1;
      
      cqlsh:ks1> 
      
      cqlsh:ks1> CREATE COLUMNFAMILY users (
             ...   KEY varchar PRIMARY KEY, password varchar, gender varchar,
             ...   session_token varchar, state varchar, birth_year bigint);
      
      cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
      
      cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
      
      cqlsh:ks1> SELECT * FROM users WHERE key='user1';
         KEY | birth_year | gender |  password |
       user1 |       1980 |      m | ch@ngem3a |
      
      cqlsh:ks1> TRUNCATE users;
      
      // Expected, no rows returned
      cqlsh:ks1> SELECT * FROM users WHERE key='user1';
         KEY |
       user1 |
      
      // Expected, no rows returned
      cqlsh:ks1> SELECT * FROM users;
      
      

        Issue Links

          Activity

          Hide
          Jonathan Ellis added a comment -

          Weird, since truncate doesn't create tombstones – it blows the data away entirely.

          Show
          Jonathan Ellis added a comment - Weird, since truncate doesn't create tombstones – it blows the data away entirely.
          Hide
          Brandon Williams added a comment -

          CASSANDRA-2855 only affects hadoop.

          Show
          Brandon Williams added a comment - CASSANDRA-2855 only affects hadoop.
          Hide
          Yuki Morishita added a comment -

          This change in behavior comes from CASSANDRA-3424, which is fixed in 1.0.3.
          See Jonathan's commented in above ticket(https://issues.apache.org/jira/browse/CASSANDRA-3424?focusedCommentId=13145954&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13145954) for current behavior.

          Show
          Yuki Morishita added a comment - This change in behavior comes from CASSANDRA-3424 , which is fixed in 1.0.3. See Jonathan's commented in above ticket( https://issues.apache.org/jira/browse/CASSANDRA-3424?focusedCommentId=13145954&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13145954 ) for current behavior.
          Hide
          Jonathan Ellis added a comment -

          Thanks for tracking that down, Yuki. I'll put together a patch.

          Show
          Jonathan Ellis added a comment - Thanks for tracking that down, Yuki. I'll put together a patch.
          Hide
          Jonathan Ellis added a comment -

          Hmm. I don't think there's a quick fix for this. StorageProxy/ReadVerbHandler doesn't distinguish between "row exists but not the columns you asked for" (should include empty row in the resultset) and "row doesn't exist at all" (should not).

          Show
          Jonathan Ellis added a comment - Hmm. I don't think there's a quick fix for this. StorageProxy/ReadVerbHandler doesn't distinguish between "row exists but not the columns you asked for" (should include empty row in the resultset) and "row doesn't exist at all" (should not).
          Hide
          Cathy Daw added a comment -

          Not sure if you guys are aware, but this behavior still exists in 1.0.3.

          Show
          Cathy Daw added a comment - Not sure if you guys are aware, but this behavior still exists in 1.0.3.
          Hide
          Shotaro Kamio added a comment -

          This issue causes following python-cql incorrect behavior (rowcount is incorrect).
          http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=10

          Show
          Shotaro Kamio added a comment - This issue causes following python-cql incorrect behavior (rowcount is incorrect). http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=10
          Hide
          Eric Evans added a comment -
          Show
          Eric Evans added a comment - This was introduced by https://issues.apache.org/jira/browse/CASSANDRA-3424
          Hide
          Sylvain Lebresne added a comment -

          This has been fixed in CQL3 by CASSANDRA-3982. Should we close this one as duplicate as I'm not sure we have a good fix for CQL2?

          Show
          Sylvain Lebresne added a comment - This has been fixed in CQL3 by CASSANDRA-3982 . Should we close this one as duplicate as I'm not sure we have a good fix for CQL2?
          Hide
          Jonathan Ellis added a comment -

          I don't think there's a good way to fix this in CQL2.

          Show
          Jonathan Ellis added a comment - I don't think there's a good way to fix this in CQL2.

            People

            • Assignee:
              Jonathan Ellis
              Reporter:
              Cathy Daw
              Reviewer:
              Jonathan Ellis
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development