[ 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