Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-6221

CQL3 statements not executed properly inside BATCH operation.

Agile BoardAttach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Bug
    • Status: Resolved
    • Priority: Normal
    • Resolution: Duplicate
    • Fix Version/s: 2.0.2
    • Component/s: None
    • Labels:
    • Environment:

      Running on Linux RHEL 6.2 with just a single node cluster. A very basic configuration. You need a CQL3 table with a composite key. Bug occurs while attempting to do both a DELETE and INSERT INTO operation inside a BATCH block.

    • Severity:


      I'm encountering a problem introduced in 2.0.0 where I have 2 CQL3 statements within a BEGIN BATCH - APPLY BATCH operator and the first one seems to be ignored. Both statements operate on the same table and the first one does a DELETE of an existing record, followed by an INSERT of a new record. The table must have a composite key. NOTE that this worked fine in 1.2.10.

      Here is a simple example of CQL3 statements to reproduce this:

      – Following table has a composite key.
      CREATE TABLE users (
      user_id bigint,
      id bigint,
      name varchar,
      PRIMARY KEY(user_id, id)

      – Insert record with key <100,1>
      INSERT INTO users (user_id,id,name) VALUES (100,1,'jdoe');

      – Following returns 1 row as expected.
      SELECT * FROM users;

      – Attempt to delete <100,1> while inserting <100,2> as BATCH
      DELETE FROM users WHERE user_id=100 AND id=1;
      INSERT INTO users (user_id,id,name) VALUES (100,2,'jdoe');

      – Following but should return only <100,2> but <100,1> is also returned
      SELECT * FROM users;
      The output from the first select which is correct:

      user_id | id | name
      100 | 1 | jdoe

      The output from the second select which is incorrect is:

      user_id | id | name
      100 | 1 | jdoe
      100 | 2 | jdoe

      Only the second row (<100,2>) should've been returned. This was the behavior in 1.2.10.


        Issue Links




              • Created:

                Issue deployment