[
https://issues.apache.org/jira/browse/CASSANDRA-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14357067#comment-14357067
]
Benedict edited comment on CASSANDRA-8947 at 3/11/15 3:50 PM:
--------------------------------------------------------------
Except that native cells don't actually test equality correctly against each
other (they treat each other as a CellName). This can itself be fixed, but was
(iirc) considered fine at the time because we never actually have two native
cells to perform equality on, and it would require an extra step in the
equality function. I'm not 100% certain it's worth messing with. -I'm
comfortable doing so in tandem with this patch if you prefer, though.- I have a
funny recollection they interact in a non-obvious way (which should definitely
have been documented), since it is used for CellName equality tests
was (Author: benedict):
Except that native cells don't actually test equality correctly against each
other (they treat each other as a CellName). This can itself be fixed, but was
considered fine at the time because we never actually have two native cells to
perform equality on, and it would require an extra step in the equality
function. I'm not 100% certain it's worth messing with. I'm comfortable doing
so in tandem with this patch if you prefer, though.
> Cleanup Cell equality
> ---------------------
>
> Key: CASSANDRA-8947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8947
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 2.1.4
>
> Attachments: cleanup_cell_equality.txt
>
>
> As pointed out by [~dbrosius], it is possible for AbstractCell to generate
> false positive equality assertions if, e.g., a non-expiring cell is replaced
> by an expiring equivalent. It's not clear to me if this would ever be a real
> problem, since we would reconcile correctly, and as such equality would
> unlikely ever be a problem (it's used rarely, only really for hash maps I
> think (although auditing this is difficult) in which the hash code would also
> be different, and by which point we should have resolved conflicts). It's
> also a very small exposure profile, with either non-ttl'd writes mixed with
> ttl'd, or a delete of a value representing the deletion timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
