[
https://issues.apache.org/jira/browse/CASSANDRA-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574757#comment-14574757
]
Sylvain Lebresne commented on CASSANDRA-9462:
---------------------------------------------
bq. I've inserted an assertion in bounds construction to ensure we never
create a bound that wraps that is not a Range.
This is already asserted in the actual implementations ctors (Bounds,
IncludingExcludingBounds and ExcludingBounds).
bq. any input on the history of this class
What I can tell you is that we used to only have the {{Range}} class, which is
the one that is the most used since our token ranges are really {{Range}}).
That's also why {{Range}} has some methods the other don't have like
{{normalize}} and {{deoverlap}} (we never bothered generalizing those methods
to the other implementation because we haven't had a need for it). That's also
why the other version are not allowed to wrap: we hadn't needed it so far so
that was simpler.
bq. if implementing unwrap() for all versions of AbstractBounds is illadvised
for some reason?
Well, as said above, the other versions can't wrap by construction so their
{{unwrap}} is properly implemented.
I haven't really look at the test failure though, so I don't understand yet
what the problem is and why you think {{AbstractBounds}} is to be blame (if you
could clarify, that would be awesome). I'm not particularly in love with the
current AbstractBound classes implementation so I have sympathy for the idea of
cleaning them up a bit, but I think we still need to understand what problem
we're trying to solve and which risks/benefits there is before rushing into it.
> ViewTest.sstableInBounds is failing
> -----------------------------------
>
> Key: CASSANDRA-9462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9462
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Ariel Weisberg
> Fix For: 3.x, 2.1.x, 2.2.x
>
>
> CASSANDRA-8568 introduced new tests to cover what was DataTracker
> functionality in 2.1, and is now covered by the lifecycle package. This
> particular test indicates this method does not fulfil the expected contract,
> namely that more sstables are returned than should be.
> However while looking into it I noticed it also likely has a bug (which I
> have not updated the test to cover) wherein a wrapped range will only yield
> the portion at the end of the token range, not the beginning. It looks like
> we may have call sites using this function that do not realise this, so it
> could be a serious bug, especially for repair.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
