[jira] [Commented] (CASSANDRA-8947) Cleanup Cell equality
[ https://issues.apache.org/jira/browse/CASSANDRA-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357049#comment-14357049 ] Sylvain Lebresne commented on CASSANDRA-8947: - +1 (nit: I'd make the test run on both buffer and native cells, just because that's easily done) 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)
[jira] [Commented] (CASSANDRA-8947) Cleanup Cell equality
[ https://issues.apache.org/jira/browse/CASSANDRA-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357101#comment-14357101 ] Sylvain Lebresne commented on CASSANDRA-8947: - Indeed. Well, I guess we could test one buffer cell against a native one for the sake of exercising the changes to the native parts, but feel free to do that on commit if you're good with it. 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)
[jira] [Commented] (CASSANDRA-8947) Cleanup Cell equality
[ https://issues.apache.org/jira/browse/CASSANDRA-8947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14357067#comment-14357067 ] Benedict commented on CASSANDRA-8947: - 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)
