Add a global ID to every IPF object to enable extensions

[fiammybe]

At the moment, it is impossible to uniquely identify an object in a ImpressCMS site. Every module and subsystem has their own internal ID, which makes it difficult to have site-wide functionalities over module boundaries. In Oracle, we could have something called a sequence, which could be used by different tables to make sure that every ID number is only used once in the entire system. However, other database systems don't provide this kind of functionality, and adding a PHP-based version of it is not as robust (what with objects that are created concurrently for example?)

If we extend the base ipf_object with a GUID ID, that would make sure that every object has a unique ID, without follow-up or check on the side of the core.

https://github.com/ramsey/uuid would be a possible library for that.

[MekDrop]

We have https://github.com/ImpressCMS/impresscms/blob/74e880e9c6f7306a80498cb9f079ef61f20c6bee/libraries/icms/ipf/Object.php#L104 Maybe it needs some improvements but I think it should work for most cases.

[fiammybe]

That's a good start. I had to go to the Handler class to go and find where the ID is assigned though.

[MekDrop]

Id is always same as defined keyName in handler (it's one of objecthandler constructor params). Only one issue I see is that current implementation doesn't work with multi primary keys. In that case id tries to cast array to string first and return bad result. Probably, we should fix that, because it's possible to get objects by multi key in ipf handler but not id.

[skenow]

In SugarCRM/vTiger/yetiCRM, there is an entity table that manages IDs for all objects. For all objects that have IDs, there is another DB table that stores the last used ID #. I have to believe the ID # for an object is not determined until it is created, rather than on initiating the new object. Obtaining the ID on save avoids the collisions of concurrent objects being created.

[fiammybe]

Correct, the concurrent creation of new objects is why I was looking at GUIDs, you kinda let the GUID algorithm take care of that for you. And an id can only exist on the moment of persisting information, not before.

What I want to avoid is that the handling of Ids is done by the modules, and certainly not a combination of id’s (moduleID-objecttype-objectid). Related to that will be the correct cascade : on storing the object, you want to store all the related objects (ratings, tags, other elements) after you have created the initial object, because you will need to retrieve the object ID in order to link them together.

[fiammybe]

@skenow the table that manages the last id for an object is used to avoid problems with the situations where multiple objects are creatd at exactly the same time. When you do a max(id) from your table, you get the maximum at that moment, but you could have the problem that multiple users are creating an object at the same instant.

What we would need it to have the possibility to identify an object with 1 id. When I look for object 15, I should be able to retrieve the base object properties without even needing to know the type of the object.

[github-actions[bot]]

This issue was automatically marked as stale

[fiammybe]

Still think this will be useful. I'll look into this.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or assign sombody or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or assign sombody or this will be closed in 5 days.