Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 13 Nov 2014 17:25:34 +0000 (UTC)
From: "Benjamin Lerer (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12742677.1411117503000.492826.1415899534223@Atlassian.JIRA>
In-Reply-To: <JIRA.12742677.1411117503000@Atlassian.JIRA>
References: <JIRA.12742677.1411117503000@Atlassian.JIRA>
 <JIRA.12742677.1411117503932@arcas>
Subject: [jira] [Commented] (CASSANDRA-7981) Refactor SelectStatement
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14210048#comment-14210048 ] 

Benjamin Lerer commented on CASSANDRA-7981:
-------------------------------------------

The patch is there: [branch|https://github.com/blerer/cassandra/compare/CASSANDRA-7981]
The Restriction building and handling has been extracted form {{SelectStatement}} into {{StatementRestrictions}} so it should be reusable. As restrictions on the partition key  or on the clustering columns where always used together as if they were one restriction I wrapped them behind a {{PrimaryKeyRestrictions}} interface and made an implementation for normal restrictions, multi-column restrictions and token restrictions. Doing so removed the reliability problems caused by the fact that we were trying to a make muti-column restrictions or token restrictions fit to the single restriction model. 

> Refactor SelectStatement
> ------------------------
>
>                 Key: CASSANDRA-7981
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7981
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
>             Fix For: 3.0
>
>
> The current state of the code of SelectStatement make fixing some issues or adding new functionnalities really hard. It also contains some functionnalities that we would like to reuse in ModificationStatement but cannot for the moment.
> Ideally I would like to:
> * Perform as much validation as possible on Relations instead of performing it on Restrictions as it will help for problem like the one of #CASSANDRA-6075 (I believe that by clearly separating validation and Restrictions building we will also make the code a lot clearer)
> * Provide a way to easily merge restrictions on the same columns as needed for #CASSANDRA-7016
> * Have a preparation logic (validation + pre-processing) that we can easily reuse for Delete statement #CASSANDRA-6237
> * Make the code much easier to read and safer to modify.


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