[
https://issues.apache.org/jira/browse/CASSANDRA-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-9711:
----------------------------------------
Component/s: Core
> Refactor AbstractBounds hierarchy
> ---------------------------------
>
> Key: CASSANDRA-9711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9711
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Sylvain Lebresne
> Priority: Major
> Fix For: 4.x
>
>
> As it has been remarked in CASSANDRA-9462 and other tickets, the API of
> {{AbstractBounds}} is pretty messy. In particular, it's not terribly
> consistent nor clear on it's handling of wrapping ranges. It also doesn't
> make it easily identifiable if an {{AbstractBounds}} can be wrapping or not,
> and there is a lot of place where the code assumes it's not but without
> really checking it, which is error prone. It's also not a very nice API to
> use (the fact their is 4 different classes that don't even always support the
> same methods is annoying).
> So we should refactor that API. How exactly is up for discussion however.
> At the very least we probably want to stick to a single concrete class that
> know if it's bounds are inclusive or not. But one other thing I'd personally
> like to explore is to separate ranges that can wrap from the one that cannot
> in 2 separate classes (which doesn't mean they can't share code, they may
> even be subtypes). Having 2 separate types would:
> # make it obvious what part of the code expect what.
> # would probably simplify the actual code: we unwrap stuffs reasonably
> quickly in the code, so there probably is a lot of operations that we don't
> care about on wrapping ranges and lots of operations are easier to write if
> we don't have to deal with wrapping.
> # for the non-wrapping class, we could trivially use a different value for
> the min and max values, which will simplify stuff a lot. It might be harder
> to do the same for wrapping ranges (especially since a single "wrapping"
> value is what IPartitioner assumes; of course we can change IPartitioner but
> I'm not sure blowing the scope of this ticket is a good idea).
> As a side note, Guava has a
> [Range|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Range.html].
> If we do separate wrapping and non-wrapping ranges, we might (emphasis on
> "might") be able to reuse it for the non-wrapping case, which could be nice
> (they have a
> [RangeMap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/RangeMap.html]
> in particular that could maybe replace our custom {{IntervalTree}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
