UUID Generation in General, for example how to make a tracker for widgets

[amenk]

How would you do the tracking for widgets? There seems to be no field for a proper unique ID?

Or we use the title.
What happens if someone changes the title?

[aleron75]

This is one of the reason the project reached a deadlock: sometimes finding a UUID is too difficult or imposes limits.

If I have time and some help (you seem to be a good candidate and, by the way, thank you for your feedback so far) I would re-engineer the process of assigning UUIDs, demanding it to external centralized service which could bind specific environment IDs to global UUIDs, avoiding the different (and sometimes difficult/limiting) "conversion" phase implemented in Action Trackers.

What do you think?

[amenk]

Sound's cool but also I don't have so much time.

[aleron75]

Sure but a few time from some people is more than a few time from only one :-)
I could have some more spare time since October 1st, if you like I will involve you in further considerations about Mageploy evolution.

[amenk]

Also that approach sounds like additional work for the setup of the system. Am I right, that there will be a problem currently if I have different blocks with the same identifier?

[amenk]

Why you need a central service for the UUID? Can't we just add a column mageploy_uuid to all necessary tables and generate a random UUID? I don't think there is a risk for any collisions if the UUIDs are long enough. Why might add hostname and path to the entropy.

[aleron75]

--- EXAMPLE
Say you create a new product XYZ in env A and let's assume ID:42 is given. In env B the same product ID could already be taken so Mageploy translates 42 into UUID. Env B receives the information that product A has to be created and let's assume that XYZ gets ID:32 on env B.

Every time both A and B modifies XYZ Mageploy uses UUID to refer to the same entity on different envs. As you know, UUIDs result from a (sometimes difficult or limiting) conversion. This is how it works now in extreme summary.
--- /EXAMPLE

For some entities it is not so simple to identify robust conversion algorithm; widgets suffer from this issue as you spotted out.

Thus the idea of centralizing UUID generation: the first env which creates a new entity causes the centralized generator to generate a UUID for that entity.

Let's see how the previous example works with centralized UUID generator:

--- EXAMPLE
You create a new product XYZ in env A and let's assume ID:42 is given. Centralized generator assigns UUID "8b7a0bf" to A and saves the relation "A:42:8b7a0bf".

When env B gets in sync and realizes that a new entity XYZ should be created it creates it and tells centralized generator which is its generated ID (32).

Centralized generator saves the relation "B:32:8b7a0bf". At this point entity XYZ is mapped and can be identified by both A and B without any complicated (or limiting) ID conversions by simply querying the centralized UUID generator.
--- /EXAMPLE

This is the idea but I like to hear feedback from anyone.
Sincerely,
Alessandro

[aleron75]

One more thing: the idea a centralized generator is based on the need to avoid collisions.

I don't think there is a risk for any collisions if the UUIDs are long enough.

if it is viable we can get rid of centralized generator;

[amenk]

For example we could use the sha1 hash of microseconds timestamp + local entity ID + system IP. This should sufficiently avoid collisions.

[aleron75]

sounds good