[
https://issues.apache.org/jira/browse/CASSANDRA-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709381#comment-14709381
]
Benedict commented on CASSANDRA-10045:
--------------------------------------
bq. Any reason for changing the name of the row inserted in ScrubTest? Doesn't
seem related to this patch in any way.
Yes, the previous columns didn't actually exist in the {{CFMetaData}}, and
somehow this didn't break the tests. It does now, though, since we require them
to be a subset of the {{SerializationHeader}} columns
Otherwise all your suggestions sound good to me (I'll take your option 2),
except your final nit. I'm not convinced there is an idiom for this kind of
iteration, and we have plenty of examples of while loop increments/decrements
over integers. It's also much clearer this way, so unless you're really very
strongly anti I'd prefer to stick with this as it is.
Will post an update shortly.
> Sparse/Dense decision should be made per-row, not per-file
> ----------------------------------------------------------
>
> Key: CASSANDRA-10045
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10045
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Fix For: 3.0 beta 2
>
>
> Marking this as beta 1 in the hope I have time to rustle it up and get it
> reviewed beforehand. If I do not, I will let it slide, but our behaviour
> right now is not brilliant for workloads with a variance in density, and it
> should not be challenging to make a more targeted decision.
> We can also make use of CASSANDRA-9894 to make column encoding more efficient
> in many, even dense, cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
