-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow DDL before box.schema.upgrade #4592
Labels
Comments
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Oct 15, 2024
Fixes tarantool#10308 @TarantoolBot document Title: Configured names in `config:info()` and `box.info.config` An instance in the YAML configuration always has a name and always corresponds to a particular replicaset and a particular group. This is forced by the hierarchical configuration format. These names are now reported in `config:info()` and `box.info.config`. ```yaml # tarantool> config:info() # or # tarantool> config:info('v2') # or # tarantool> box.info.config --- - <..status, alerts, meta..> hierarchy: group: group-001 replicaset: replicaset-001 instance: instance-001 ... ``` The `hierarchy` field is an empty table if tarantool is started with a Lua script or in the interactive mode without a script/a config. Usually `box.info.name` equals to `box.info.config.hierarchy.instance`, but there are situations, when only one of them is reported. `box.info.config.hierarchy.instance` corresponds to the *configured* instance name and it is reported when the YAML configuration is in use. This instance name is written to the database as well, but the write operation is postponed if the database schema version is lower then needed to support the persistent names (see [1] for details). A user can meet this situation while running tarantool 3.x on data from tarantool 2.x, before the upgrading procedure is performed. On the other hand, a user may use the persistent names feature (see [2]) together with the classic approach, when tarantool is run without the configuration file, using a Lua script. In this case, `box.info.config.hierarchy` is empty, but `box.info.name` shows the name passed to `box.cfg({instance_name = <...>})` (and written to the database). The same is applicable to `box.info.replicaset.name` and `box.info.config.hierarchy.replicaset`. [1]: tarantool/doc#4592 [2]: tarantool/doc#3468
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Oct 15, 2024
Fixes tarantool#10308 @TarantoolBot document Title: Configured names in `config:info()` and `box.info.config` An instance in the YAML configuration always has a name and always corresponds to a particular replicaset and a particular group. This is forced by the hierarchical configuration format. These names are now reported in `config:info()` and `box.info.config`. ```yaml # tarantool> config:info() # or # tarantool> config:info('v2') # or # tarantool> box.info.config --- - <..status, alerts, meta..> hierarchy: group: group-001 replicaset: replicaset-001 instance: instance-001 ... ``` The `hierarchy` field is an empty table if tarantool is started with a Lua script or in the interactive mode without a script/a config. Usually `box.info.name` equals to `box.info.config.hierarchy.instance`, but there are situations, when only one of them is reported. `box.info.config.hierarchy.instance` corresponds to the *configured* instance name and it is reported when the YAML configuration is in use. This instance name is written to the database as well, but the write operation is postponed if the database schema version is lower then needed to support the persistent names (see [1] for details). A user can meet this situation while running tarantool 3.x on data from tarantool 2.x, before the upgrading procedure is performed. On the other hand, a user may use the persistent names feature (see [2]) together with the classic approach, when tarantool is run without the configuration file, using a Lua script. In this case, `box.info.config.hierarchy` is empty, but `box.info.name` shows the name passed to `box.cfg({instance_name = <...>})` (and written to the database). The same is applicable to `box.info.replicaset.name` and `box.info.config.hierarchy.replicaset`. [1]: tarantool/doc#4592 [2]: tarantool/doc#3468
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Oct 15, 2024
Fixes tarantool#10308 @TarantoolBot document Title: Configured names in `config:info()` and `box.info.config` An instance in the YAML configuration always has a name and always corresponds to a particular replicaset and a particular group. This is forced by the hierarchical configuration format. These names are now reported in `config:info()` and `box.info.config`. ```yaml # tarantool> config:info() # or # tarantool> config:info('v2') # or # tarantool> box.info.config --- - <..status, alerts, meta..> hierarchy: group: group-001 replicaset: replicaset-001 instance: instance-001 ... ``` The `hierarchy` field is an empty table if tarantool is started with a Lua script or in the interactive mode without a script/a config. Usually `box.info.name` equals to `box.info.config.hierarchy.instance`, but there are situations, when only one of them is reported. `box.info.config.hierarchy.instance` corresponds to the *configured* instance name and it is reported when the YAML configuration is in use. This instance name is written to the database as well, but the write operation is postponed if the database schema version is lower then needed to support the persistent names (see [1] for details). A user can meet this situation while running tarantool 3.x on data from tarantool 2.x, before the upgrading procedure is performed. On the other hand, a user may use the persistent names feature (see [2]) together with the classic approach, when tarantool is run without the configuration file, using a Lua script. In this case, `box.info.config.hierarchy` is empty, but `box.info.name` shows the name passed to `box.cfg({instance_name = <...>})` (and written to the database). The same is applicable to `box.info.replicaset.name` and `box.info.config.hierarchy.replicaset`. [1]: tarantool/doc#4592 [2]: tarantool/doc#3468
Totktonada
added a commit
to Totktonada/tarantool
that referenced
this issue
Oct 16, 2024
Fixes tarantool#10308 @TarantoolBot document Title: Configured names in `config:info()` and `box.info.config` An instance in the YAML configuration always has a name and always corresponds to a particular replicaset and a particular group. This is forced by the hierarchical configuration format. These names are now reported in `config:info()` and `box.info.config`. ```yaml # tarantool> config:info() # or # tarantool> config:info('v2') # or # tarantool> box.info.config --- - <..status, alerts, meta..> hierarchy: group: group-001 replicaset: replicaset-001 instance: instance-001 ... ``` The `hierarchy` field is an empty table if tarantool is started with a Lua script or in the interactive mode without a script/a config. Usually `box.info.name` equals to `box.info.config.hierarchy.instance`, but there are situations, when only one of them is reported. `box.info.config.hierarchy.instance` corresponds to the *configured* instance name and it is reported when the YAML configuration is in use. This instance name is written to the database as well, but the write operation is postponed if the database schema version is lower then needed to support the persistent names (see [1] for details). A user can meet this situation while running tarantool 3.x on data from tarantool 2.x, before the upgrading procedure is performed. On the other hand, a user may use the persistent names feature (see [2]) together with the classic approach, when tarantool is run without the configuration file, using a Lua script. In this case, `box.info.config.hierarchy` is empty, but `box.info.name` shows the name passed to `box.cfg({instance_name = <...>})` (and written to the database). The same is applicable to `box.info.replicaset.name` and `box.info.config.hierarchy.replicaset`. [1]: tarantool/doc#4592 [2]: tarantool/doc#3468
Totktonada
added a commit
to tarantool/tarantool
that referenced
this issue
Oct 21, 2024
Fixes #10308 @TarantoolBot document Title: Configured names in `config:info()` and `box.info.config` An instance in the YAML configuration always has a name and always corresponds to a particular replicaset and a particular group. This is forced by the hierarchical configuration format. These names are now reported in `config:info()` and `box.info.config`. ```yaml # tarantool> config:info() # or # tarantool> config:info('v2') # or # tarantool> box.info.config --- - <..status, alerts, meta..> hierarchy: group: group-001 replicaset: replicaset-001 instance: instance-001 ... ``` The `hierarchy` field is an empty table if tarantool is started with a Lua script or in the interactive mode without a script/a config. Usually `box.info.name` equals to `box.info.config.hierarchy.instance`, but there are situations, when only one of them is reported. `box.info.config.hierarchy.instance` corresponds to the *configured* instance name and it is reported when the YAML configuration is in use. This instance name is written to the database as well, but the write operation is postponed if the database schema version is lower then needed to support the persistent names (see [1] for details). A user can meet this situation while running tarantool 3.x on data from tarantool 2.x, before the upgrading procedure is performed. On the other hand, a user may use the persistent names feature (see [2]) together with the classic approach, when tarantool is run without the configuration file, using a Lua script. In this case, `box.info.config.hierarchy` is empty, but `box.info.name` shows the name passed to `box.cfg({instance_name = <...>})` (and written to the database). The same is applicable to `box.info.replicaset.name` and `box.info.config.hierarchy.replicaset`. [1]: tarantool/doc#4592 [2]: tarantool/doc#3468
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since: 3.3.0
From now on, DDL before schema upgrade is allowed for schema versions >=
2.11.1 (previously it was forbidden in 3.0.0 release). In documentation
we need to create a list of features, which are forbidden until some
versions. Current state:
Requested by @Serpentian in tarantool/tarantool@aeb53ca.
The text was updated successfully, but these errors were encountered: