[cgma-dev] Switching unique IDs to RFC4122 UUIDs

[Tim Tautges]

[cc'ing cubit-dev, since they will also want to weigh in on this...]



On 09/20/2013 04:08 PM, David Thompson wrote:
> Hi all,
>
> 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.  Large models are indeed likely to have conflicting ids with other large files, but those could be handled 
by keeping track of the current file you're reading and the entities read by each file (not efficient, I know, but 
simple to implement).

> One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. For instance,
> SubEntitySet::renumerate, CAEntityId::actuate, and PartitionEngine::restore_from_attrib all do some kind of math
> (increment/decrement) on UIDs. This is not supported by any UUID implementation I'm aware of.
>

Looking at CAEntityId::actuate, and the GSaveOpen::get_id_inc, it appears that this increment is used in place of a file 
id or indicator (haven't checked that to be sure, but I'd be very surprised if that wasn't the case), but that's for 
entity ids, not for unique ids.  SubEntitySet's use seems like EntityId, not UID; same goes for 
PartitionEngine::restore_from_attrib.

> 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.

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.

- tim

>
> Thanks, David
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
             fax: (608) 263-4499      Madison, WI 53706