[
https://issues.apache.org/jira/browse/CASSANDRA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873823#action_12873823
]
AJ Slater edited comment on CASSANDRA-1145 at 5/31/10 7:32 PM:
---------------------------------------------------------------
attached is a storage-conf and example python program.
it requires the python thrift bindings and pycassa:
http://github.com/vomjom/pycassa
usage: ./bugtest.py [TEXT1 TEXT2..]
arguments on the command line are inserted into cassandra and then range_get is
used to get and pretty print them, with timestamps.
it counts the multiple copies of the same rows at the end.
was (Author: ajslater):
attached is a storage-conf and example python program.
it requires the python thrift bindings and pycassa:
http://github.com/vomjom/pycassa
> Reading with CL > ONE returns multiple copies of the same column per key.
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-1145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1145
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6.1
> Environment: ubuntu jaunty
> Reporter: AJ Slater
> Attachments: bugtest.py, storage-conf.xml
>
>
> Testing with 0.6-trunk today:
> Reading with CL > ONE returns multiple copies of the same column per key
> consistent with the replicas queried before return. i.e, for RC=3, a QUORUM
> read yields 2 copies and an ALL read returns 3.
> This is with pycassa get_range() which is using get_range_slice()
> I see the same behavior with 0.6.1 and 0.6.2 debs
> If my experience is not unique, anyone using get_range_slice is now deluged
> with duplicate data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
