Skip to content
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

Open
TarantoolBot opened this issue Oct 9, 2024 · 0 comments
Open

Allow DDL before box.schema.upgrade #4592

TarantoolBot opened this issue Oct 9, 2024 · 0 comments
Labels

Comments

@TarantoolBot
Copy link
Collaborator

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:

  • DDL before box.schema.upgrade - forbidden until 2.11.1
  • Persistent names - forbidden until 2.11.5
  • Persistent triggers - forbidden until 3.1.0
    Requested by @Serpentian in tarantool/tarantool@aeb53ca.
@veod32 veod32 added the 3.3 label Oct 10, 2024
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
Labels
Projects
None yet
Development

No branches or pull requests

2 participants