cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11213) Improve ClusteringPrefix hierarchy
Date Tue, 23 Feb 2016 15:22:18 GMT


Branimir Lambov commented on CASSANDRA-11213:

I did it slightly differently: range tombstones do make an explicit distinction between bound
and boundary, so it isn't that valuable for them to have a shared bound class to use; it made
more sense for me to isolate the bound concept from its uses and avoid conversion between
the slice ends and the corresponding range markers:
- Moved the bound concept outside of {{Slice}} and {{RangeTombstone}}. What used to be a {{Slice.Bound}}
is now a {{ClusteringBound}}.
- Made a {{ClusteringBoundary}} type and changed the markers to use bound/boundary directly.
- Added a shared {{AbstactClusteringBound}} ancestor for the few bits of code that need to
be able to work with both.
- Had to name the types {{ClusteringX}} to avoid naming conflict between {{ClusteringBound}}
and cql3 statements {{Bound}}.


> Improve ClusteringPrefix hierarchy
> ----------------------------------
>                 Key: CASSANDRA-11213
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Branimir Lambov
>             Fix For: 3.x
> As noted by [~blambov] on CASSANDRA-11158, having {{RangeTombstone.Bound}} be a subclass
of {{Slice.Bound}} is somewhat inconsistent. I'd argue in fact that conceptually neither should
really be a subclass of the other as none is a special case of the other and they are use
in strictly non-overlapping places ({{Slice.Bound}} is for slices which are used for selecting
data while {{RangeTombstone.Bound}} is for range tombstone which actually represent some type
of data).
> We should figure out a cleaner hierarchy of this, which probably mean slightly changing
the {{ClusteringPrefix}} hierarchy.

This message was sent by Atlassian JIRA

View raw message