[
https://issues.apache.org/jira/browse/CASSANDRA-10681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018508#comment-15018508
]
Jordan West commented on CASSANDRA-10681:
-----------------------------------------
I prefer the version that makes it explicit that some operations may be
performed across the entire table data set (indexes/sstables) but if we are not
going that route I would vote we use the other patch Pavel posted, which avoids
the unnecessary unused instance construction.
Also, is there a need to introduce a new `IndexBuildTask class` or can we just
use `SecondaryIndexBuilder` as the interface and subclass it? Is there a
concern about re-using the existing class but making it abstract?
> make index building pluggable via IndexBuildTask
> ------------------------------------------------
>
> Key: CASSANDRA-10681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10681
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local Write-Read Paths
> Reporter: Pavel Yaskevich
> Assignee: Pavel Yaskevich
> Priority: Minor
> Labels: sasi
> Fix For: 3.x
>
> Attachments: 0001-add-table-support-for-multi-table-builds.patch,
> 0001-make-index-building-pluggable-via-IndexBuildTask.patch
>
>
> Currently index building assumes one and only way to build all of the indexes
> - through SecondaryIndexBuilder - which merges all of the sstables together,
> collates columns etc. Such works fine for built-in indexes but not for SASI
> since it's attaches to every SSTable individually. We need a "IndexBuildTask"
> interface (based on CompactionInfo.Holder) to be returned from Index on
> demand to give power to SI interface implementers to decide how build should
> work. This might be less effective for CassandraIndex, since this effectively
> means that collation will have to be done multiple times on the same data,
> but nevertheless is a good compromise for clean interface to outside world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
