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
• Take over column UUIDs when creating columns from schema
• 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

[blizzz]

@enjeck resolved all your comments. For you convenience, I have the essential changes still left in the unstashed fixup-PRs, and then there is just one additional commit. I would leave this now as the basework and would implement the create and update logic in a seperate PR.

[blizzz]

Locally, all Playwright tests pass…

[blizzz]

• have to generate UUIDs also for selection options during migration