[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703710#comment-14703710
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
Patch available [here|https://github.com/belliottsmith/cassandra/tree/9901]
* This has kept the {{isByteOrderComparable}} flag in the
{{ClusteringComparator}} as I hadn't factored in the extra cost of performing a
{{List}} lookup in cases where we can avoid it
* In AbstractType we also extract the isByteOrderComparable into a boolean flag
for one less level of indirection when performing this test
* We directly call {{compareCustom}} in {{ClusteringComparator}}, but
everywhere else we rely on the final implementation of {{compare()}}
> 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)
