[
https://issues.apache.org/jira/browse/CASSANDRA-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-1145:
------------------------------------
Attachment: 0001-Sort-keys.patch
Adding a fix patch that will sort the keys before getRangeSlice uses them to
get their associated rows. That will keep them sorted when they are sent back
to the client, for the CollatingIterator.
> 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
> Assignee: Jeremy Hanna
> Priority: Critical
> Fix For: 0.6.5
>
> Attachments: 0001-Added-a-unit-test.patch, 0001-Sort-keys.patch,
> bugtest.py, demo.patch, 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.
