cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9701) Split Kind.REGULAR into SIMPLE and COMPLEX
Date Wed, 01 Jul 2015 20:23:04 GMT


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:
>             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

View raw message