Sometimes entities have a natural key property that is not necessarily the entity (database) key. E.g. a vehicle is a BaseIdentityIdEntity but has a natural key “VIN” (Vehicle Identification Number).
The idea is that the (optional) natural key property of an entity could be specified in the CUBA meta model (within CUBA studio). Benefits are for example:
Mostly the user “knows” the natural key of an entity. In a foreign key relationship to an entity it would be faster for him to enter the natural key instead of opening the select screen. The fieldgroups could use “smart” SearchPickerFields that allow to search by the natural key by default (without any further custom implementation).
In distributed environment (where data are imported from other sources) it would be easy to implement a custom UUID creator (see Create UUID based in composite key - CUBA.Platform) that generates the UUID based on the specified natural key.
The first point is clear for me, I’ve seen this in many business requirements. But the second one I don’t quite understand - what is the point of having UUID created from a natural key instead of just randomly generated? Subsequent search?
Hi Konstantin. We are importing lot of entities from external data sources. The import mechanism needs to determine which entities needs to be added, deleted or modified based on the natural keys.
The first idea was to create an UUID based on the natural key so the import comparisons just rely on that UUID. E.g. a vehicle with the vehicle identification number “W0L000051T2123456” always have the same UUID.
But now we choose to just compare the natural keys instead of UUIDs. So as you said, i also think the first mentioned benefit is most relevant.