[cgma-dev] Switching unique IDs to RFC4122 UUIDs

[David Thompson]

Hi Tim,

>> I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across multiple large models are much less likely to have duplicate IDs.
> 
> While I think this is worth considering (and doing, if it were just CGM), I'm not sure it's so critical for file operations.

I'm not sure what you mean by "file operations."

>> One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. ...
>> Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I thought lived in different "namespaces" (sequential integers for CAUniqueId and random integers for TDUniqueId). Was I wrong to think this? If not, why does CAEntityId add the same id_inc to both its own ID and its merge-partner's (which appears to be obtained in some places using TDUniqueId::find_td_unique_id)?
> 
> Here I think you're wrong, the unique id and entity id are different concepts, and the find_td_unique_id in CAEntityId is used strictly with UIDs and not with entity ids.

Thanks, I will take a more careful look there.

> To summarize, while I think it would be useful to use a standards-compliant UUID, in practice I'm guessing it's going to be difficult to motivate the Cubit project to change what they do to accomplish this, even if you/we implement all the changes in CGM and below.  Cubit guys, please chime in here.  It appears to me that GSaveOpen was probably meant to do what a true UUID change would, that is, guarantee different UUID spaces in different files, alas they solved it a different way.


OK. If we cannot find a good way to get by without UUIDs then we'll look to add them as a third attribute instead of a replacement for TDUniqueID.

	Thanks,
	David