[
https://issues.apache.org/jira/browse/CASSANDRA-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14727288#comment-14727288
]
Benjamin Lerer commented on CASSANDRA-6237:
-------------------------------------------
Thanks for the review.
{quote} For future reference: as a reviewer it would have been very helpful to
have the StatementType / StatementRestrictions refactors mentioned in the
comments above kept as discrete commits leading up to the work for Range
deletions, rather than as one monolithic commit to review.{quote}
I am sorry for that. I ran into some issues when rebasing after CASSANDRA-8099
and add to merge all my commits together.
{quote}I'm hesitant about us crystallizing our unit tests around the exact
verbiage of the error messages we're throwing (see: assertInvalidMessage being
added into DeleteTest and InsertTest). Checking exception type alone doesn't
buy us the 100% confirmation that the exception we think was raised was
actually raised, however it allows for future modifications of the details of
those exceptions without having to track down failed unit tests that are
explicitly dependent upon them. I'm on the fence with this one; if you're
strongly attached to the assertInvalidMessage approach, stick with it.{quote}
In the CQL layer, all the validation errors are returned as
{{InvalidRequestException}} and I had a few cases were the error messages
returned to the user were not the expected ones.
I have also seen cases where the message parameters were not rendered as
expected. In my opinion, changing the error message in the test does not
require too much work and it guaranty you that you are not breaking the way we
handle invalid queries when you are modifying the code.
The new patch is
[here|https://github.com/apache/cassandra/compare/trunk...blerer:6237-3.0]
* The unit test results are [here|
http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-6237-3.0-testall/lastCompletedBuild/testReport/]
* The dtest results are
[here|http://cassci.datastax.com/view/Dev/view/blerer/job/blerer-6237-3.0-dtest/lastCompletedBuild/testReport/]
> 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 beta 2
>
> 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)
