[
https://issues.apache.org/jira/browse/CASSANDRA-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699798#comment-14699798
]
Benedict commented on CASSANDRA-9901:
-------------------------------------
bq. What I could suggest, on top of
If we were to say "instead of" and we stuck with the enum, I'd be with you. One
of the advantages of using an enum that I did not enumerate was the possibility
of performing more efficient despatch for "mixed" clustering data (i.e. with
some byte comparable, some not), especially given we now always consult the
boolean parameter from the class property, since the comparisons of each
clustering column is performed in a different method call now (so if we have a
different class property to consult as cheaply, we may as well do so).
Having two virtual invocations instead of one on this path is a pretty
significant burden we should avoid, however.
bq. From a quick look, it looks like the patch will log warning for every
internal type that is not byte comparable
{code}
+ if
(!getClass().getPackage().equals(AbstractType.class.getPackage()))
+ logger.warn("Type " + this + " is not comparable by its
unsigned sequence of raw bytes. A future (major) release of Cassandra may
remove support for such arbitrary comparisons, however upgrade steps will be
provided to ensure a smooth transition.");
{code}
Admittedly I haven't confirmed this, but it looks fine to me, and I'll double
check before we commit.
bq. Also, logging in CFMetadaData.rebuild is going to be more noisy than
necessary
I prefer to log more often than less, since there's more chance of it being
spotted. I don't think we rebuild _so_ often - just during schema changes, no?
> 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.0 rc1
>
>
> 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)
