[
https://issues.apache.org/jira/browse/IGNITE-24828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-24828:
-------------------------------------
Description:
*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.
*Motivation*
We should provide storage profiles switching on demand.
*Definition of Done*
> 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.
> *Motivation*
> We should provide storage profiles switching on demand.
> *Definition of Done*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
