[
https://issues.apache.org/jira/browse/CASSANDRA-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187126#comment-14187126
]
Benjamin Lerer commented on CASSANDRA-6237:
-------------------------------------------
We have already some duplicate code in ModificationStatement and in
SelectStatement and continuing to duplicate the code is not a clean solution.
The ideal solution would be to extract the Restrictions handling from
SelectStatement (which I do as part of CASSANDRA-7981) to be able to reuse it
within ModificationStatement. It would ultimatly allow us to support for the
DELETE statements every thing which is supported by the SELECT statement.
CASSANDRA-7016 need CASSANDRA-7981 for another reason which is that the way we
handle token restrictions is not robust and is preventing me to solve properly
CASSANDRA-7016.
I got blocked on a couple of tickets because of the current design of
SelectStatement was preventing me to solve them properly or in a bullet proof
way. It is what motivated me to refactor SelectStatement and fix properly all
the issues that I faced.
> Allow range deletions in CQL
> ----------------------------
>
> Key: CASSANDRA-6237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6237
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Benjamin Lerer
> Priority: Minor
> Labels: cql, docs
> Fix For: 3.0
>
> Attachments: CASSANDRA-6237.txt
>
>
> We uses RangeTombstones internally in a number of places, but we could expose
> more directly too. Typically, given a table like:
> {noformat}
> CREATE TABLE events (
> id text,
> created_at timestamp,
> content text,
> PRIMARY KEY (id, created_at)
> )
> {noformat}
> we could allow queries like:
> {noformat}
> DELETE FROM events WHERE id='someEvent' AND created_at < 'Jan 3, 2013';
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
