cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Klages (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-6221) CQL3 statements not executed properly inside BATCH operation.
Date Sun, 20 Oct 2013 21:04:55 GMT
Andy Klages created CASSANDRA-6221:

             Summary: CQL3 statements not executed properly inside BATCH operation.
                 Key: CASSANDRA-6221
             Project: Cassandra
          Issue Type: Bug
         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.
            Reporter: Andy Klages
             Fix For: 2.0.0

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.
    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.

This message was sent by Atlassian JIRA

View raw message