feat: add UUIDs to columns

[blizzz]

Base for structural updates, cf. my comment in #2504 (comment)

• Add UUIDs to Tables or consider unnecessary
• Add UUIDs to Views or consider unnecessary
• Add UUIDs to multiselection options
• Treat multiselection default on export and import

[blizzz]

Add UUIDs to Tables or consider unnecessary
Add UUIDs to Views or consider unnecessary

Would not implement it now as it is not required currently. If necessary for an auto-update of a table without specifying local ids, this can be always added alter on easily.

[Koc]

I guess that uuid should be unique across table (we need add unique id for table_id+uuid).

Here use-cases that we need to support:

Table update between instance

• a developer designs and evolves a table schema locally using UI
• exports the schema
• imports it into production
• later changes the schema locally again
• and wants to apply those schema updates to the already existing production table without recreating it from scratch

Table duplocation a single NC instance

A second scenario is especially important for end users who do not have separate environments:

• a developer designs and evolves a table schema using UI
• exports the schema
• imports it into another table on same instance

[blizzz]

I guess that uuid should be unique across table (we need add unique id for table_id+uuid).

Here use-cases that we need to support:

Table update between instance

* a developer designs and evolves a table schema locally using UI

* exports the schema

* imports it into production

* later changes the schema locally again

* and wants to apply those schema updates to the already existing production table without recreating it from scratch

Yupp, this scenario is exactly what are having in mind.

Table duplocation a single NC instance

A second scenario is especially important for end users who do not have separate environments:

* a developer designs and evolves a table schema using UI

* exports the schema

* imports it into another table on same instance

This would also be covered, as importing always requires a target table. So having columns with the same UUID across different tables is intentional. Hence importing, so the plan, would only affect the columns on the targeted table.

[enjeck]

some comments

[enjeck]

so it will be nice to have a a UNIQUE index?

[blizzz]

This is not the idea here, only within the same table. Several users may import (and eventually update) the same table from a template or different system, then you would have the same (or similar) column rows, but associated with different tables.