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]

QBMapper::insert() only writes fields returned by getUpdatedFields(). So we need to call markFieldUpdated('uuid') ?

[enjeck]

do we ever call this? and is it being protected useful. Cuz when the mapper reads a row, Entity::fromRow() runs (Entity.php:50):

phpforeach ($row as $key => $value) {
    $prop = $instance->columnToProperty($key);
    $instance->setter($prop, [$value]);   // <-- calls the generic setter()
}

It calls the generic setter() method directly with the property name 'uuid'. i don't think it calls setUuid()? So the custom method and its RuntimeException are skipped?

[enjeck]

Since the property is ?string $uuid

Suggested change

	* @method string getUuid()
	@method ?string getUuid()

[enjeck]

do we need to update ResponseDefinitions.php?

[enjeck]

In ColumnService.php, we call new Column(). Do we have to do assignUuid() there?

[enjeck]

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