[
https://issues.apache.org/jira/browse/IGNITE-25140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-25140:
-------------------------------------
Epic Link: IGNITE-24953 (was: IGNITE-22115)
> Move table lifecycle logic for colocation in a separate manager
> ----------------------------------------------------------------
>
> Key: IGNITE-25140
> URL: https://issues.apache.org/jira/browse/IGNITE-25140
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mikhail Efremov
> Assignee: Mikhail Efremov
> Priority: Major
> Labels: ignite-3
>
> *Description*
> We have a pretty common pattern for tables handling in colocation track. As
> illustration {{ChangeIndexStatusTaskController}} may be considered. The
> common idea: we can not rely on {{Catalog}} in case of proper tables'
> lifecycle management. A table catalog descriptor may existing, but table may
> not yet. And otherwise if there no the descriptor then the corresponding
> table and its resources may exist until low watermark will be updated. So we
> can't for colocation's zones rely on code like the follow:
> {code:java}
> Collection<CatalogTableDescriptor> tableDescriptors = catalogService
> .catalog(catalogService.latestCatalogVersion())
> .tables(partitionKey.zoneId());
> {code}
> ...because we may potentially miss to handle a table by it descriptor.
> So {{ChangeIndexStatusTaskController}}:
> # track tables in a set in case of table creation;
> # uses {{DestroyTableEvent}} record for track a table drops with prioritized
> queue by drop event catalog version token;
> # do a proper handling on actual table destruction without missing any table
> entity.
> We need to generalize this pattern because this isn't a single place of usage
> of such approach during and after the colocation track will be done.
> *Motivation*
> This refactoring will speed up colocation development in cases of tables
> lifecycle event handling, will reduce code duplication and then reduce a
> mistakes during the colocation track implementation.
> *Definition of done*
> * New {{TableLifecycleManager}} is introduced.
> * It allows simultaneous subscription on {{CatalogEvent.TABLE_CREATE}},
> {{CatalogEvent.TABLE_DROP}}, {{LowWatermarkEvent.LOW_WATERMARK_CHANGED}}.
> * Accepts custom handlers at least for the last event.
> * {{DestroyTableEvent}} is moved into the manager.
> * {{ChangeIndexStatusTaskController}} is simplified by the new manager
> instance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
