[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[
https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610966#comment-14610966
]
Benedict commented on CASSANDRA-9701:
-
That turned out to make the patch dramatically smaller. I opted to just,
effectively, pre-compute the sort order of the Kind + isComplex. Which makes it
optimal and removes the risk of breaking our sort order by accident later.
Force pushed, and awaiting CI.
{noformat}
src/java/org/apache/cassandra/config/ColumnDefinition.java | 16
+---
1 file changed, 9 insertions(+), 7 deletions(-)
{noformat}
> Split Kind.REGULAR into SIMPLE and COMPLEX
> --
>
> Key: CASSANDRA-9701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9701
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Benedict
>Assignee: Benedict
>Priority: Minor
> Fix For: 3.0 beta 1
>
>
> A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into
> their own Kind, we can simplify the compareTo method and obtain greater
> certainty that we don't (now or in future) accidentally break the required
> sort order that simple << complex.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[ https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610959#comment-14610959 ] Benedict commented on CASSANDRA-9701: - I'll go with Option 3, and see what we think of the result. > Split Kind.REGULAR into SIMPLE and COMPLEX > -- > > Key: CASSANDRA-9701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict >Priority: Minor > Fix For: 3.0 beta 1 > > > A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into > their own Kind, we can simplify the compareTo method and obtain greater > certainty that we don't (now or in future) accidentally break the required > sort order that simple << complex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[ https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610948#comment-14610948 ] Benedict commented on CASSANDRA-9701: - bq. left the enum itself alone bq. At least I think we should enforce the isComplex() check before the others, since we depend so strongly on it. That would be Option 1. Option 2 eliminates a number of operations on ColumnDefinition.compareTo(), which is likely to be invoked more often than any other method in the codebase. Option 3 would be to have an enum-like object that encodes KIND + Complex? efficiently for comparison, perhaps with Kind still floating around, encapsulated, as is. > Split Kind.REGULAR into SIMPLE and COMPLEX > -- > > Key: CASSANDRA-9701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict >Priority: Minor > Fix For: 3.0 beta 1 > > > A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into > their own Kind, we can simplify the compareTo method and obtain greater > certainty that we don't (now or in future) accidentally break the required > sort order that simple << complex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[ https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610936#comment-14610936 ] Aleksey Yeschenko commented on CASSANDRA-9701: -- I would rather you left the enum itself alone, and stored simple/complex elsewhere. > Split Kind.REGULAR into SIMPLE and COMPLEX > -- > > Key: CASSANDRA-9701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict >Priority: Minor > Fix For: 3.0 beta 1 > > > A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into > their own Kind, we can simplify the compareTo method and obtain greater > certainty that we don't (now or in future) accidentally break the required > sort order that simple << complex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[ https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610908#comment-14610908 ] Benedict commented on CASSANDRA-9701: - Hmm. I'm not sure why, but I think I was thinking of them as like clustering columns and only taking frozen types. Well, I'm relatively easy. At least I think we should enforce the isComplex() check before the others, since we depend so strongly on it. However since these comparison methods will probably be one of the main intra-node CPU time sinks, it's probably worth incurring the slight ugliness of STATIC_SIMPLE and STATIC_COMPLEX to merge both of those checks into the kind comparison. > Split Kind.REGULAR into SIMPLE and COMPLEX > -- > > Key: CASSANDRA-9701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict >Priority: Minor > Fix For: 3.0 beta 1 > > > A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into > their own Kind, we can simplify the compareTo method and obtain greater > certainty that we don't (now or in future) accidentally break the required > sort order that simple << complex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[
https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610871#comment-14610871
]
Sylvain Lebresne commented on CASSANDRA-9701:
-
Hum, that doesn't seem to work for static ones (which can also be both simple
and complex). Could split it to {{STATIC_SIMPLE}} and {{STATIC_COMPLEX}} I
suppose.
> Split Kind.REGULAR into SIMPLE and COMPLEX
> --
>
> Key: CASSANDRA-9701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9701
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Benedict
>Assignee: Benedict
>Priority: Minor
> Fix For: 3.0 beta 1
>
>
> A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into
> their own Kind, we can simplify the compareTo method and obtain greater
> certainty that we don't (now or in future) accidentally break the required
> sort order that simple << complex.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
[ https://issues.apache.org/jira/browse/CASSANDRA-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14610866#comment-14610866 ] Benedict commented on CASSANDRA-9701: - Patch available [here|https://github.com/belliottsmith/cassandra/tree/9701] > Split Kind.REGULAR into SIMPLE and COMPLEX > -- > > Key: CASSANDRA-9701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Benedict >Assignee: Benedict >Priority: Minor > Fix For: 3.0 beta 1 > > > A small refactor as follow up to 8099. By splitting SIMPLE and COMPLEX into > their own Kind, we can simplify the compareTo method and obtain greater > certainty that we don't (now or in future) accidentally break the required > sort order that simple << complex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
