cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
Date Wed, 15 Jul 2015 15:16:05 GMT


Benedict commented on CASSANDRA-9705:

bq. But what is currently called ComplexColumnData cannot reasonably implement Cell, not with
the current definition/API of Cell at least.

I guess, to clarify, I'm somewhat taking exception to the use of {{Column}} in the name alone,
without any reference to the {{Row}} component. A {{ColumnFilter}}, for instance, does not
filter {{ColumnData}}, but filters {{ColumnDefinition}}. A {{RowFilter}} filters {{ColumnData}},
however (or the whole {{Row}}). This is inconsistent, and I would rather we made it consistent.
Even renaming to {{RowDatum}} would be a little more consistent, but still not very consistent.

So my proposal is that we overload the _logical concept_ of a cell (lowercase) to mean {{(Clustering
Prefix, Column) -> Values}}, and special case to simple cells (where {{card(Values) <=
1}}) and complex cells (where {{card(Values) >= 1}}). Another way of formulating this is
that a cell is the collection of {{(Clustering Prefix, Column) -> Value}} maps, but a simple
cell is one where this map is guaranteed to be of size 1. This could be achieved by:

* Renaming {{ComplexColumnData}} to {{ComplexCell}}; and
* either:
** Renaming {{ColumnData}} to {{AbstractCell}} (or, perhaps, {{RowCell}}, or any other {{XCell}});
** Renaming {{Cell}} to {{SimpleCell}}, and {{ColumnData}} to {{Cell}}

The latter would further lead to normalising the concept of simple/complex around the place,
somewhat, I think. However it may mean typing "Simple" a bit more than we might otherwise.

I'll note that, in my opinion at least, this is more of a clarification of the prior concept
of cell that naturally follows from the other internal engine refactoring. This has previously
been a bit of a gray zone, nomenclature-wise, and very few people will have used the verbiage
around complex data internals, since very few people interact with it (or understand it).
I'm hoping both will change for the better post 8099, but making our language a bit clearer
will no doubt help.

> Simplify some of 8099's concrete implementations
> ------------------------------------------------
>                 Key: CASSANDRA-9705
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 3.0 beta 1
> As mentioned in the ticket comments, some of the concrete implementations (for Cell,
Row, Clustering, PartitionUpdate, ...) of the initial patch for CASSANDRA-8099 are more complex
than they should be (the use of flyweight is typically probably ill-fitted), which probably
has performance consequence. This ticket is to track the refactoring/simplifying those implementation
(mainly by removing the use of flyweights and simplifying accordingly).

This message was sent by Atlassian JIRA

View raw message