Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 27 Jan 2016 09:37:39 +0000 (UTC)
From: "Benjamin Lerer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12852685.1438893169000.222597.1453887459800@Atlassian.JIRA>
In-Reply-To: <JIRA.12852685.1438893169000@Atlassian.JIRA>
References: <JIRA.12852685.1438893169000@Atlassian.JIRA>
 <JIRA.12852685.1438893169630@arcas>
Subject: [jira] [Updated] (CASSANDRA-10010) Paging on DISTINCT queries
 repeats result when first row in partition changes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Lerer updated CASSANDRA-10010:
---------------------------------------
    Attachment: 10010-2.2.txt

|[utest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10010-testall/]|[dtest|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-10010-dtest/]

The problem seems to be only affecting range queries. The patch makes sure that for distinct range queries only the partition keys are compared and not the rows.

PR for the DTest is [here|https://github.com/riptano/cassandra-dtest/pull/774]. It adds some testing for multi partition queries to the original test of [~thobbs]

> Paging on DISTINCT queries repeats result when first row in partition changes
> -----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-10010
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10010
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Tyler Hobbs
>            Assignee: Benjamin Lerer
>            Priority: Minor
>             Fix For: 2.1.x, 2.2.x
>
>         Attachments: 10010-2.2.txt
>
>
> When paging, we always check new pages to see if they start with the same row that the previous page ended with, and if so, we trim that row to avoid duplicates.  With {{DISTINCT}} queries, we only fetch the first row in each partition.  If that row happens to change (it's deleted, or another row is inserted at the front of the partition) in between fetching the two pages, our check for a matching row will fail, resulting in a duplicate row being returned.
> It seems like the correct fix is to handle {{DISTINCT}} queries specially and only check to see if the partition key matches the last returned one instead checking that the rows match.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)