[
https://issues.apache.org/jira/browse/IGNITE-26798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Efremov updated IGNITE-26798:
-------------------------------------
Priority: Minor (was: Major)
> Throw validation exception for attempts to create table without specified
> zone nor default zone but there are existing zones
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-26798
> URL: https://issues.apache.org/jira/browse/IGNITE-26798
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mikhail Efremov
> Assignee: Mikhail Efremov
> Priority: Minor
> Labels: ignite-3
>
> *Description*
> In IGNITE-26425 there was a change that made default zone created lazily.
> This will lead to better cluster start experience, but still the issues
> arise: let's assume a user created one or more zones for it's production
> database, but forgot to set any as default. Then if user will execute
> standard SQL create table statement without zone specification then cluster
> will create excessive default zone and will place table and probably data in
> this wrong (implicit) zone.
> *Motivation*
> There are 2 user mistakes: at first user forgot to do {{alter zone .. set
> default}}, and the last is {{create table .. }} without zone. Let's consider
> both issues separately.
> What we can do with forgotten {{alter zone}} without any default zone set
> (means there no table that was created without specified zone and there no
> more zone in cluster)? We may mark the first created zone as default. This
> solution contains 2 caveats:
> # It's implicit action that is the type of behavior we're trying to remove:
> assume that user created several zone and didn't noticed/forgot of this
> implicit rule; user script will throw no exception, but all tables without
> specified zone will be created in the first created zone with it's data that
> highly likely will be unwanted as behavior and all process will be redone by
> user that may didn't notice about the fact that all data will be placed on
> the first zone (no exception is thrown!).
> # This workaround doesn't defend us from empty default zone: if later user
> will remove the first created zone, then without explicit alteration of the
> existed ones we will have no default zone; also this behavior is presented
> right now with pre-created default zone too.
> So, looks like we shouldn't do this action implicit, also we may consider to
> add an option to set default property with {{create zone}} DDL statement, but
> this is out of scope.
> Then, the last mistake is {{create table ..}} without zone while there are
> set of already created zone. Now we'll create a special fully default zone
> just to comply standard DDL statement for table creation and in implicit way.
> Instead of failure with suggestion message about both kind of mistake like:
> {{There are several existing zones, specify any as table's zone or alter any
> zone as default zone [zones=[us_zone, eu_zone, apac_zone]].}}. We don't
> create a zone with default options for {{create table ... zone
> unexisted_zone}}, we warn user about a potential mistake. It's explicit way
> to solve this type of user input mistake.
> And the last but not least we may compare user's effort to solve this
> scenarios with both solutions (implicit vs explicit).
> Let's assume that user expects implicit behavior with {{create table
> new_table; insert into new_table (id, val) values ...;}} script. Then user
> will fail with the message and will do any of one action: {{alter zone
> eu_zone set default}} or add zone in the script {{create table new_table zone
> eu_zone; insert into new_table (id, val) values ...;}} or will create
> explicitly new zone with defaults and alter it as default {{create zone
> default_zone storage profiles ['default']; alter zone default_zone set
> default;}} and the script will works as expected. Notice that user had been
> warned and shouldn't do any undo actions like zone/table drop or something.
> Otherwise let's assume that user expects explicit behavior with the same
> script. The script will be executed successfully, but after a time user will
> find that instead of any warning the new table will be created in newly
> created {{Default}} zone without any filter applied and user's customers in
> EU zone struggles with data access. Then user have to create in parallel with
> wrongly allocated resources new table (name collision should be solved),
> migrate data from wrong table, drop the wrong table and unnecessary
> {{Default}} zone. Much more problems just because potentially wrong script
> passed validation.
> Previously started cluster will face no any compatibility issues because
> there is already created default zones on catalog initialization or user's
> custom zones set is provided. The only change is the behavior on newly
> started clusters.
> *Definition of Done*
> # In case if there no default zone, no specified zone name for create table
> catalog command and non empty existing zone set in catalog, the we have to
> throw {{CatalogValidationException}} with the message that contains
> suggestion how to fix user's create table statement.
> # Corresponding tests on catalog create table command and validations should
> be provided.
> # Broken tests should be fixed, mostly by altering created in test zone as
> default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
