Feature request: Extend every table by a globally unique UUID

[noseshimself]

In order to facilitate new features (even up to a distributed database of objects with slow synchronization or turning the database into a collection of objects of arbitrary types and properties) a necessary first step would provide a globally unique object ID to anything inserted into the database (and the logical second step would be adding type and version identifiers as follow up step).

In the case of mariadb 10.6+ it would be sufficient to add

`ID` UUID NOT NULL DEFAULT uuid(),

to every table and (right now) ignore the column. UUIDs will be stored as binary values (instead of char(36)) and handled efficiently.

MySQL 8 and older mariadb versions would require packing and unpacking as well as generation by stored procedures. mariadb 10.5 would use

`ID` BINARY (16) NOT NULL DEFAULT UNHEX (SYS_GUID ()) PRIMARY KEY;

but would need special handling of the values if used by the database clients (to insert the dashes in the right places).

As I sincerely doubt that there are Kraft users generating more than a few dozen new objects per seconds the overhead of adding these identifiers is negligible.

[dragotin]

Please see my comment in #213

[noseshimself]

Please see my comment in #213

I did. Right now I'm trying to hijack the Kraft database for a proof of concept involving NocoDB and automation. If that is working as intended I will probably try getting an automated import from Kimai into Kraft as having parallel invoice generation is a shortcut to hell or alcoholism.

Direct modification of some application's internal data has never been a good idea but in the case of Kraft it's the fastest way to do so.

PS: Using https://kimai.org is highly recommended. The only better solution I know is somewhere in the price range of 10000€...

[dragotin]

Direct modification of some application's internal data has never been a good idea but in the case of Kraft it's the fastest way to do so.

Lets rather think of a proper API for that. Having Kraft docs synced on an ownCloud gives relatively easy ways of building REST APIs to manipulate these... What do you think?

[noseshimself]

Probably a better idea. But a lot more work