Why must UIDs be allocated when documents are created?

When you index a big tree of objects (e.g. applied rules), indexing by multiple threads could generate too many conflicts, if UIDs are allocated when objects are indexed. Indexing an object requires indexing the parent object. So this recursive indexing activities modifies many objects to assign UIDs. This raises conflict errors if one thread tries to index a part of the tree, while another thread tries to index another part of the same tree. To avoid this, UIDs must be allocated as soon as objects are created.

Also, if an object is referred to by another object (i.e. a relation), the UID of that object is required to index this object. So the easiest way to solve this dependency problem is to assign an UID to that object when it is created.

Why don't we use OIDs instead of UIDs?

When you rename an object, Zope actually copies the original object to a new object, and removes the original object. So the OID of the new object differs. If this object is referred to by other objects, these objects must be reindexed. If the object is a category, the number of related objects can be huge.

But this possibilty must be investigated carefully.

I found a reason. If an ERP5 site mounts multiple storages, the uniqueness of OIDs is not guaranteed among the whole site.

How to check if two objects has the same UID (i.e. a confliction)?

There is no easy way, because catalogObject may not distinguish between a duplication of an UID and renaming. One way is to record renaming operations.

Where can it happen that two objects have the same UID?

This happens when you clear the catalog and reindex objects. Because MySQL generates the maximum value + 1 for AUTO_INCREMENT, it can allocate the same UID as a reserved UID after you clear the catalog. If you make a new object before existing objects are completely indexed, portal_catalog assigns the same UID to the new object. So a conflict occurs.

There are some ways to avoid this. One is to use a counter in ZODB, like CMFUid. If portal_catalog does not reset this counter when tables are remade, portal_catalog never allocates the same UIDs. Another is to insert a dummy catalog row which has the maximum UID number in the previous table. Then, MySQL does not reserve UIDs less than the UIDs allocated for existing objects.

Another possibilty is to modify / assign an UID manually. This should not happen, if the user has a sane mind.

Why shouldn't UIDs change?

Because UIDs are referred to by other objects by relations.