[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711061#comment-14711061
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
bq. I'd left ClusteringComparator.compareComponent as is (before the patch).
This may lead to suboptimal compilation. The result would most likely be two
occurrences of the {{FastByteOperations.compareUnsigned}} calls, with however
much of these can be inlined into the method duplicated (most likely a
significant quantity).
bq. then an assert in compare() is probably better.
I've explicitly moved the assert into the ClusteringComparator constructor
(which is the only call site for the assertion), and have introduced a check to
enforce that the {{compareCustom}} method is not overridden. This way we get
assertions for free, as {{NOT_COMPARABLE}} results in
{{!isByteOrderComparable}}, so we will hit the
{{UnsupportedOperationException}} in this case as a final resort.
> 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
>
>
> 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)
