[
https://issues.apache.org/jira/browse/CASSANDRA-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641921#comment-14641921
]
Sylvain Lebresne commented on CASSANDRA-9459:
---------------------------------------------
bq. I believe CASSANDRA-8717 is/was broken by CASSANDRA-8099. The post
reconcilliation processing step is still there, but it looks like the code for
scanning all ranges was removed from StorageProxy.
I think we're good, at least it's the intention. The "scan all ranges" option
pre-CASSANDRA-8099 is just a ugly to ask for the code to not respect the user
limit before the post-reconciliation function is called, since the limit is
only thing that makes us stop scanning all ranges. However,
post-CASSANDRA-8099, the user-limit is enforce _after_ the post-reconciliation
call. So an implementation that want to use CASSANDRA-8717 can consume as much
of the iterator passed to the post-reconciliation function as it wants/needs,
and it will get all ranges if it consumes it all in particular. In other words,
we now support CASSANDRA-8717 with just the post-reconciliation function, but
that's a feature since it's cleaner.
> SecondaryIndex API redesign
> ---------------------------
>
> Key: CASSANDRA-9459
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9459
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Fix For: 3.0 beta 1
>
>
> For some time now the index subsystem has been a pain point and in large part
> this is due to the way that the APIs and principal classes have grown
> organically over the years. It would be a good idea to conduct a wholesale
> review of the area and see if we can come up with something a bit more
> coherent.
> A few starting points:
> * There's a lot in AbstractPerColumnSecondaryIndex & its subclasses which
> could be pulled up into SecondaryIndexSearcher (note that to an extent, this
> is done in CASSANDRA-8099).
> * SecondayIndexManager is overly complex and several of its functions should
> be simplified/re-examined. The handling of which columns are indexed and
> index selection on both the read and write paths are somewhat dense and
> unintuitive.
> * The SecondaryIndex class hierarchy is rather convoluted and could use some
> serious rework.
> There are a number of outstanding tickets which we should be able to roll
> into this higher level one as subtasks (but I'll defer doing that until
> getting into the details of the redesign):
> * CASSANDRA-7771
> * CASSANDRA-8103
> * CASSANDRA-9041
> * CASSANDRA-4458
> * CASSANDRA-8505
> Whilst they're not hard dependencies, I propose that this be done on top of
> both CASSANDRA-8099 and CASSANDRA-6717. The former largely because the
> storage engine changes may facilitate a friendlier index API, but also
> because of the changes to SIS mentioned above. As for 6717, the changes to
> schema tables there will help facilitate CASSANDRA-7771.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
