[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14638778#comment-14638778 ] Aleksey Yeschenko commented on CASSANDRA-9705: -- This passes my tests now, thanks. Sorry for not running them as part of overeview myself. Simplify some of 8099's concrete implementations Key: CASSANDRA-9705 URL: https://issues.apache.org/jira/browse/CASSANDRA-9705 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 (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14637487#comment-14637487 ] Aleksey Yeschenko commented on CASSANDRA-9705: -- FYI, since our upgrade tests are currently not being run by cassci (because of simultaneous Java7+Java8 issues), cassci had not caught an upgrade issue. LegacySchemaMigrator breaks, trying to read from the old (2.1) sstables. Simplify some of 8099's concrete implementations Key: CASSANDRA-9705 URL: https://issues.apache.org/jira/browse/CASSANDRA-9705 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 (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635504#comment-14635504
]
Aleksey Yeschenko commented on CASSANDRA-9705:
--
Fill disclosure: the patch set is very sizable, so this is not a complete
thorough review - merely an overeview answering the question 'can we merge this
into trunk as is, and finish the review afterwards?'.
Broken:
1. {{ClusteringComponent.compareComponent()}} is broken for v1 == v2 == null
(the first ternary is wrong). We need tests for this.
Looks fishy:
2. {{RangeTombstoneBoundaryMarker}} {{createCorrespondingCloseMarker()}} and
{{createCorrespondingOpenMarker()}} have swapped their behavior in this patch
set. I'm assuming that this was intentional, but if so, it at least warrants a
comment
Unused fields and method arguments that are confusing (some not new to this
patch set). Most of these, if not all, are benign, but some wasted some time to
figure out:
3. {{UnfilteredDeserializer.OldFormatDeserializer.nextFlags}} is unused
4. {{MemtableAllocator.SubAllocator}} fields {{owns}} and {{reclaiming}} are
unused
5. {{BitTableWriter.StatsCollector.collectStatsOn()}} is unused (but turns out
to be benign)
6. {{SerializationHelper.endOfComplexColumn()}} method has an unused {{column}}
argument
Nits:
7. {{PartitionUpdate.CounterMark}} class should be static
Nomenclature is arguable, and there is plenty of minor nits that I won't list
here (but would urge Sylvain to go through each file in IDEA and pay attention
to the inspections).
Once cassci is happy (which is to say, once it shows that these changes don't
break anything new), I'm fine with committing it to trunk. Overall it's a
welcome simplification that should fix and make a lot of things easier
(including Tyler's backward compat work and Sam's 2i work).
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631743#comment-14631743
]
Sylvain Lebresne commented on CASSANDRA-9705:
-
I've pushed an additional commit to the branch that refactor the {{Reader}} in
{{SSTableIterator}} and {{SSTableReverseIterator}}. The new implementations
directly return the reader for the {{slice}} method, but more generally avoid
pretty much all the code duplication there was (and is simpler/cleaner as a
result).
bq. There are some unused imports around the place
Forgot to answer that one. I don't know a good way to find those imports that
are unused due to this patch (and looking manually is not very fun), so if
we're good with it, I propose to just run an import reorganization on the
project on commit.
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628375#comment-14628375 ] Benedict commented on CASSANDRA-9705: - Yep, I'll leave it there. I can see we simply had two inconsistent (with each other, not internally) concepts of cell, and I'm happy to leave it there on that front. It doesn't mean I'm happy about ColumnData, though: it's still a very ambiguous term, and leaves us without a good term for the _general instance_ of the value(s) associated with a given (row, column) pair. Column data does not disambiguate between, e.g. all values taken by that column for all rows, nor possibly schema data associated with the column. Data is generally an empty term in a database. I'd _prefer_ it if we could come up with something better, but I won't push any further beyond that statement of desire. I will propose one possibility, though: Gaol. A Gaol is, after all, a collection of cells. Sometimes only 1 :) Simplify some of 8099's concrete implementations Key: CASSANDRA-9705 URL: https://issues.apache.org/jira/browse/CASSANDRA-9705 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 (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628296#comment-14628296
]
Sylvain Lebresne commented on CASSANDRA-9705:
-
I somehow sense that we're not going to reach an agreement easily, and I'd
rather not spend too much time on this on this ticket for what I think is
largely orthogonal to the main goals of the ticket. So I'm gonna answer your
last remarks as a form of conclusion, but I'll ask that if your still unhappy
with this, we create a follow-up ticket for that naming issue and continue the
discussion there. It'll focus the conversation, making it easier for others to
share their opinion too.
bq. 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.
I wouldn't say that's true at all. A {{ColumnData}} _is_ the data for a
{{ColumnDefinition}}, so filtering {{ColumnDefinition}} _is_ filtering full
{{ColumnData}} (hence {{ColumnFilter}} does filter {{ColumnData}}). In fact,
it's very much the idea behind the use of {{Column}}. As for {{RowFilter}}, it
_always_ filter whole rows (based on condition on the {{ColumData}} but still).
So, without making claims of perfection, I do actually think it's pretty
consistent.
bq. Renaming {{ComplexColumnData}} to {{ComplexCell}}
I frankly dislike the idea of calling {{ComplexCell}} something that's gonna
hold cells. That, I personally find confusing and inconsitent (Beauty is in
the eye of the beholder). To me, the name 'cell' has a notion of atomicity:
it corresponds to a single value with it's related informations (timestamp,
tll, ...). It's in that sense that I say it corresponds to the existing,
pre-8099 notion of cell. And it's that notion that I don't see a good reason to
change.
bq. renaming to {{RowDatum}} would be a little more consistent
For the reasons above, I disagree it would be more consistent, or even better,
since a {{ColumnData}} is again very much the data for a given column of a
row. But as it is indirectly also some datum from the row, let say that I
wouldn't fight such renaming too hard. I'd still would want to gather other
opinions on a separate, focused ticket however.
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628001#comment-14628001
]
Benedict commented on CASSANDRA-9705:
-
I have not reached the main guts of the changes yet. A few initial comments, as
they've reached sufficient critical mass. I apologise if some of this stuff is
blurring the lines of scope with 8099, but I want to raise things as they occur
to me.
* {{ColumnData}} and {{ComplexColumnData}} are a bit confusingly named, to my
mind, at least, because it is {{(Column x Row) Data}}. Especially since
{{Cell}} implements {{ColumnData}} but is also a _component_ of a
{{ComplexColumnData}} in which context it doesn't seem very reasonable to call
it a {{ColumnData}} at all. Could we not just have {{ComplexCell}} (made up of
{{Cell}}), both implementing {{AbstractCell}}; or a {{SimpleCell}} both
implementing {{Cell}}?
* Is it really better to have {{Row}} implement {{IterableColumnData}} than
{{IterableCell}}? It looks like we use the latter more often, and have a lot
of new expansions of for-loop into uglier while-loop-with-Iterator. Perhaps
whichever we opt to not make default, we should return an {{Iterable}} for the
opposing method, to help retain clarity? With Java 8 it is not at all ugly, and
most likely also of zero runtime cost.
* I like the migration to {{Builder}}, but we still have a lot of methods
labelled {{writeX}}
* There are some unused imports around the place
* {{SSTableReversedIterator:365}}: double assignment of {{markerEnd}}
* {{SSTableReversedIterator.ReverseIndexedReader}}: {{slice}} effectively moves
the outer class itself, and duplicates/mirrors some of its functionality. Could
we not merge the behaviour, so that slice() returns {{this}}, or another
instance of the same class?
** Same applies to {{SSTableIterator.ForwardIndexedReader}}, and to some extent
the distinction between {{ForwardReader/ForwardIndexedReader}} and
{{ReverseReader/ReverseIndexedReader}}.
* {{CompositesSearcher:176}}: unused property
* {{ObjectSizes:44}}: unused property
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628212#comment-14628212
]
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}}); or
** 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: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628176#comment-14628176
]
Sylvain Lebresne commented on CASSANDRA-9705:
-
I've pushed a commit to the branch with some of those first remarks fixed. I
discuss the rest below.
bq. {{ColumnData}} and {{ComplexColumnData}} are a bit confusingly named, to my
mind, at least, because it is {{(Column x Row) Data}}.
The idea is that {{ColumnData}} is the data for a single column within a row.
For a simple column, that data is just a single cell, so making {{Cell}}
implement {{ColumnData}} directly felt simpler (we could, I suppose, have a
{{SimpleColumnData}} that {{Cell}} would extend, but I don't see what that
would buy us). And {{ComplexColumnData}} is the implementation for complex
columns. I understand we don't all find the same things intuitive/confusing,
but I have to admit that as far as naming goes, it's one I'm reasonably happy
with.
bq. Could we not just have ComplexCell (made up of Cell), both implementing
AbstractCell; or a SimpleCell both implementing Cell?
Not totally sure to understand the suggestion. But what is currently called
{{ComplexColumnData}} cannot reasonably implement {{Cell}}, not with the
current definition/API of {{Cell}} at least.
I'll also add that the current cell concept is pretty close to our existing
concept, which is strongly suspect is a good thing, so I'm reluctant to change
what it means too much (in case you were suggesting along those lines).
bq. Is it really better to have Row implement {{IterableColumnData}} than
{{IterableCell}}?
I do strongly believe it is. Mainly because when you iterate over the cells,
you're missing the complex column deletion informations, so iterating on cells
should only be done when you know that it's ok to do so. Also, quite a few of
the places where we iterate on cells is for 2ndary index, and that's because
the current API is fundamentally cell based. But that's actually inefficient:
typically, if you're not indexing a collection column, there is no point in
checking all the individual cells for that column, but that's what we do. That
should be fixed by the 2ndary API refactor though, so I expect the direct cell
iterations to diminish, and iteration on {{ColumnData}} to be by far
predominant. As it should be.
That said, totally agreed about the {{Iterable}} point and I've made that
change in the new commit.
bq. I like the migration to Builder, but we still have a lot of methods
labelled {{writeX}}
I've fixed a few ({{RangeTombstoneMarker.Builder}}, which had a few, was
actually unused), but it's hard to make sure I found all occurrences (write
is a pretty common symbol prefix in the code base), so if you find some
remaining, I'll be happy to fix them too.
Regarding {{SSTable\[Reversed\]Iterator}} readers, I agree it's not perfect in
term of code duplication. I'll have a fresh look at trying to clean it up but
it will take a tad more time.
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[ https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14628220#comment-14628220 ] Benedict commented on CASSANDRA-9705: - (I'll also note I'm not pushing hard for this, I just think it improves things) Simplify some of 8099's concrete implementations Key: CASSANDRA-9705 URL: https://issues.apache.org/jira/browse/CASSANDRA-9705 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 (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14624757#comment-14624757
]
Sylvain Lebresne commented on CASSANDRA-9705:
-
I had pushed a tad quickly on Friday so for info I've forced pushed an update
that:
# is rebased against trunk
# fixes a few minor test failures
# add a few additional comments
# switch the implementations of {{ArrayBackedRow}} and {{ComplexColumnData}}
from lists to arrays. I started with arrays for convenience but using arrays
was pretty simple in that case so that makes the objects slightly less fat.
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9705) Simplify some of 8099's concrete implementations
[
https://issues.apache.org/jira/browse/CASSANDRA-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622556#comment-14622556
]
Sylvain Lebresne commented on CASSANDRA-9705:
-
Pushed a branch for this
[here|https://github.com/pcmanus/cassandra/commits/9705]. It removes all use of
flyweights, and basically rewrite all Row, Cell and Partition implementations.
The result is admittedly a lot simpler and less error prone. I suspect it's
also faster but haven't looked at that much yet.
The patch is actually not very small because the change of implementation
allowed a lot of related simplifications. Hopefully this won't be too
disruptive on other patches, but I'd still be happy if we can get that in as
fast as possible, if only because I'd rather not spend too much time fixing
unit tests and dtests that are fixed with this or easier to.
Concretely there is 3 commits:
* the first one update the implementations of {{ClusteringPrefix}} and its
subclasses. That one is pretty simple and self-contained.
* the second one is the main meat. It rewrites most of the rest and was
unfortunately much harder to split in smaller pieces.
* the last one if kind of a follow-up: we're currently using {{LivenessInfo}}
for both {{Row}} and {{Cell}}, but after the previous patches it's barely used
by {{Cell}}. So that 3rd patch make it be only for rows, which make things
cleaner/simpler anyways.
I plan on doing another review of the whole patch on Monday and to add comments
where they are missing so there may be a few minor updates then, but it's
basically ready for review otherwise.
Simplify some of 8099's concrete implementations
Key: CASSANDRA-9705
URL: https://issues.apache.org/jira/browse/CASSANDRA-9705
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
(v6.3.4#6332)
