views:

63

answers:

1

Hello,

I wrote a test program for testing Cassandra, and I had problems reading data. Seems like Cassandra sometimes takes one key for another.

Here is my test program :

from lazyboy import *
from lazyboy.key import Key
import uuid
import random

class TestItemKey(Key):
    def __init__(self, key=None):
     Key.__init__(self, "TestMX", "TestCF", key)

class TestItem(record.Record):
    def __init__(self, *args, **kwargs):
        record.Record.__init__(self, *args, **kwargs)
        self.key = TestItemKey(uuid.uuid1().bytes)

connection.add_pool('TestMX', ['localhost:9160'])

t1 = TestItem({'test':'foo'})
t1.key = TestItemKey(uuid.UUID('3cead15a-a54e-11df-87a2-000c298d2724').bytes)
t2 = TestItem({'test':'bar'})
t2.key = TestItemKey(uuid.UUID('3cebc15a-a54e-11df-87a2-000c298d2724').bytes)
t1.save()
t2.save()

print TestItem().load(t1.key.clone())
print TestItem().load(t2.key.clone())

(The chosen UUIDs are an example of the ones causing problems)

Here is the output of this script :

root@ubuntu:/mnt/hgfs/TestMX# python test.py 
TestItem: {'test': 'foo'}
TestItem: {'test': 'foo'}

Instead of the expected result :

root@ubuntu:/mnt/hgfs/TestMX# python test.py 
TestItem: {'test': 'foo'}
TestItem: {'test': 'bar'}

Note that the script usually works great with other randomely-chosen UUIDs, but sometimes not...

+2  A: 

Sounds a lot like you're hitting https://issues.apache.org/jira/browse/CASSANDRA-1235 which is fixed in the 0.6 branch and will be in 0.6.5, the next stable release.

jbellis
Tkanks. It solved the problem for those two keys in particular. But it is still possible to find non-working ones, like `936a87e2-a5fc-11df-82c1-000c29f73b23` and `936ae9e4-a5fc-11df-82c1-000c29f73b23`.With the same result...
Pierre
ok, then you probably hit another bug (comment added after discussion on irc #cassandra)
Schildmeijer
Yep. Thank you :)
Pierre