[ https://issues.apache.org/jira/browse/CASSANDRA-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707001#comment-14707001 ]
Sam Tunnicliffe commented on CASSANDRA-9459: -------------------------------------------- Ok [~slebresne], the most recent commit ([afc4ea1|https://github.com/beobal/cassandra/commit/afc4ea1468a44692ef36498e2acf36a12a104bc8]) reworks the class hierarchy around {{CassandraIndexer}} along the lines of your suggestions. {{CassandraIndex}} is now an abstract class, with concrete subclasses representing the various specializations. I've kept the functions (renamed to {{CassandraIndexFunctions}}, but these are now fairly minimal. They're used where we need to do some index-type-specific thing, without having an instance of the index around (like creating a CFMetaData for the backing store for example). I've also rolled {{ColumnIndexSearcher}} and {{CassandraIndexSearcher}} together, which was eminently sensible, & removed {{ColumnIndexMetadata}}. > 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)