cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9901) Make AbstractType.isByteOrderComparable abstract
Date Thu, 27 Aug 2015 22:09:45 GMT


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:
>             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
> 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

View raw message