cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11354) PrimaryKeyRestrictionSet should be refactored
Date Mon, 21 Mar 2016 14:19:25 GMT


Benjamin Lerer commented on CASSANDRA-11354:

{quote}Is AbstractSingleRestriction still required as an abstract class? It's also possible
to implement the false returning methods on the interface directly. {quote}
I removed the {{AbstractSingleRestriction}} class and moved the {{reverseBoundIfNeeded}} method
into the {{Bound}} class.

{quote}There are two places where clustering column restrictions are "validated"{quote}
The main reason for that is that the restrictions are needed in order for the second validation.
When merging restrictions we have no guaranty of the order in which the restrictions are provided.
It could be {{SELECT * FROM myTable WHERE clustering1 = 1 AND clustering2 = 2;}} or  {{SELECT
* FROM myTable WHERE clustering2 = 2 AND  clustering1 = 1;}} 

> PrimaryKeyRestrictionSet should be refactored
> ---------------------------------------------
>                 Key: CASSANDRA-11354
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
> While reviewing CASSANDRA-11310 I realized that the code of {{PrimaryKeyRestrictionSet}}
was really confusing.
> The main 2 issues are:
> * the fact that it is used for partition keys and clustering columns restrictions whereas
those types of column required different processing
> * the {{isEQ}}, {{isSlice}}, {{isIN}} and {{isContains}} methods should not be there
as the set of restrictions might not match any of those categories when secondary indexes
are used.

This message was sent by Atlassian JIRA

View raw message