cassandra-commits mailing list archives

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


Sylvain Lebresne commented on CASSANDRA-11213:

And to expand a bit on what's above, I think we have 2 "conceptual" relationship regarding
what's currently {{ClusteringPrefix}}:
# both {{Clustering}} and {{RangeTombstone.Bound}} are identifying an {{Unfiltered}} (respectively
a {{Row}} and a {{RangeTombstoneMarker}})
# both {{Slice.Bound}} and {{RangeTombstone}} represent some bound of data.

So it feels that ideally we'd have both a super type to {{Clustering}} and {{RangeTombstone.Bound}}
(which incidentally would be what {{IndexInfo}} contains), and a {{AbstractBound}} super type
of {{Slice.Bound}} and {{RangeTombsone.Bound}} mostly for code reuse.

> 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