[TYPO3-core] Universally/Globally Unique IDentifier in core in 6.0?

[JoH asenau]

>> IMHO there is no need to replace the current behaviour completely.
>> Instead we should provide UUID support as additional feature that can be
>> enabled/used on demand. Especially export and reimport of records and
>> cross domain sharing of content will be uses cases for that, but as long
>> as there is no need for these special features the rest of the TYPO3
>> world could stay with the usual normalization and have less problems.
>
> The problem with importing records is that (numerical) uid collisions
> occur. This can be solved to an extend (as import/export does), but
> references to these records (singleViewPid in TS for example) need to be
> adjusted. With UUIDs this would be no problem.
>
> The case of the BE layouts provided by an extension (see other thread).
>
> Moving content/configuration in a dev/test/accept/production street
> would be easy.
>
> It's easy to come up with a long list of situations where a globally
> unique identifier would come in very handy. I don't see how an extra
> UUID would be a solution here if the numerical, not-so-unique uid is
> still the primary ID.

Technically you might be on the right track, when it comes to multi-DB, 
multi-system or multi-whatever usage, although there definitely will be 
performance issues with large tables, and there are more large tables 
than just the sys log when your target group is enterprise CMS users.

So as long as you are not leaving the TYPO3 sandbox you are working in, 
the current integer based UID would serve you without problems. Only for 
those cases where you have to interact with other TYPO3 based systems, 
there might be a reason for GUID/UUIDs, but still I think it would be 
anough to be able to identify a record with a GUID and then integrate it 
into the existing UID based structure of the other sandbox.

BTW: We are currently working on a multilevel edit => publish => process 
=> release staging scenario, using a FLOW3 based processor between 
different TYPO3 systems. This system completely works with the default 
uid/pid system of TYPO3 and does not even use an additional UUID field.

Another point that is completely missing in your scenarios is user 
experience.

I try to imagine the support hotline talking with a customer about 
record 21EC2020-3AEA-1069-A2DD-08002B30309D with tag 
3F2504E0-4F89-11D3-9A0C-0305E82C3301 on page 
936DA01F-9ABD-4D9D-80C7-02AF85C822A8. There is a reason why things tend 
to be human readable, which is hardly true for UUIDs.

And since most of the stuff TYPO3 is using under the hood is based on 
decimal numbers, that are evaluated by core methods as well as lots of 
major extension, it would be a huge task to switch this completely to 
GUID/UUID. Of course we got the option to have breaking changes in 6.0, 
but this does not necessarily mean that we have to put them all into 
this one release ;-)

So IMHO this might be a goal for a future TYPO3 version but would be too 
much hassle for the release plan of 6.0.

Cheers

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your gob sometimes!)
Dieter Nuhr, German comedian
Xing: http://contact.cybercraft.de
Twitter: http://twitter.com/bunnyfield
TYPO3 cookbook (2nd edition): http://www.typo3experts.com