[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14717627#comment-14717627
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
I've rebased to latest 3.0, and simply removed the {{isByteOrderComparable}}
from {{ClusteringComparator}} entirely - this will result in some extra
indirection than we have previously incurred (versus 2.1), which I'm not keen
on, but won't contest. Whomever wants to optimise this at a later date can
unpick the utility of eliminating that.
It is worth noting, this particular method is one of _the_ central methods for
the entire codebase, and we have evidence like CASSANDRA-10084 that
inefficiencies here have significant downsides, so we should consider visiting
it. However ultimately I think we need to attack our data model to make real
inroads on our comparison costs. e.g. CASSANDRA-6936, which this ticket is
intended to help enable.
> Make AbstractType.isByteOrderComparable abstract
> ------------------------------------------------
>
> Key: CASSANDRA-9901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9901
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0 beta 2
>
> Attachments: C2 compilation output
>
>
> I can't recall _precisely_ what was agreed at the NGCC, but I'm reasonably
> sure we agreed to make this method abstract, put some javadoc explaining we
> may require fields to yield true in the near future, and potentially log a
> warning on startup if a user-defined type returns false.
> This should make it into 3.0, IMO, so that we can look into migrating to
> byte-order comparable types in the post-3.0 world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
