[
https://issues.apache.org/jira/browse/IGNITE-24828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-24828:
-------------------------------------
Epic Link: IGNITE-24953 (was: IGNITE-22115)
> Add storage profiles set change in ALTER ZONE
> ---------------------------------------------
>
> Key: IGNITE-24828
> URL: https://issues.apache.org/jira/browse/IGNITE-24828
> Project: Ignite
> Issue Type: Bug
> Reporter: Mikhail Efremov
> Assignee: Mikhail Efremov
> Priority: Major
> Labels: ignite-3
>
> *Description*
> Most of options for zones are available to alter, but not storage profiles.
> Mostly, there no only a binding between DDL statement and
> {{AlterZoneCommand}} inside of {{DdlSqlToCommandConverter}}. We should add a
> proper {{DdlOptionInfo}} into {{alterZoneOptionInfos}} map:
> {code:java}
> // Some comments here
> // ALTER ZONE options.
> alterZoneOptionInfos = new EnumMap<>(Map.of(
> // ...
> STORAGE_PROFILES,
> new DdlOptionInfo<>(String.class, this::checkEmptyString,
> (builder, params) ->
> builder.storageProfilesParams(parseStorageProfiles(params)))
> ));
> {code}
> Then we should provide a restrictions on alteration: if all zone's storage
> profiles were volatile, then user shouldn't be able to add any persistent
> one. An issue there is to track zone's volatility state flag. There are
> options:
> # If user isn't able to set empty profiles set then we just may just check
> new added profiles' engines on alteration if any is persisted while the zone
> is volatile. We shouldn't persist zone's volatility flag then.
> # If user is able to set empty profiles, then we may store a flag in 2 places:
> ** in metastore itself;
> ** through catalog descriptor.
> The metastore way is preferable because a zone's volatility is an internal
> property, not a user input and should be provided in distributed way through
> a cluster. Moreover {{CatalogZoneDescriptor}} is more a zone's scheme
> description, not zone's state.
> But now any {{AlterZoneCommand}} is {{CatalogCommand}} and executes at
> {{CatalogManager#saveUpdate}} first, then it goes to {{UpdateLogImpl#append}}
> that invokes {{VersionedUpdate}} on metastore. The last is handled by
> {{UpdateListener#onUpdate}} watcher that triggers {{OnUpdateHandler#handle}}
> and only in the end of it there are local {{CatalogEvent#ZONE_ALTER}} events
> firing that are leads to {{CatalogAlterZoneEventListener#notify}}. A long and
> non-obvious chain, but the main idea that we should verify profiles in
> {{CatalogManager}} because it's the entrypoint. To provide saving zone's
> state on metastore we should provide it somehow. At least {{UpdateLogImpl}}
> uses it, so.
> *Motivation*
> We should provide storage profiles switching on demand.
> *Definition of Done*
> # We should be able to alter a zone's storage profiles through SQL and there
> should be a test for the case.
> # We should restrict a zone's storage profiles alteration in case of all
> zone's creation moment all profiles were volatile and there should be tests
> for the case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
