[Zope-CMF] cmfuid

[Chris McDonough]

On Sat, 2004-11-20 at 16:30, Jens Vagelpohl wrote:
> I like the standards-compliance, but so far haven't found a need for 
> UIDs or UUIDs in general.

Neither had I, at least until lately.

The reason I want a uid now is to be able to have a unique hash value
for objects so I can resolve that hash value to a file in a directory on
a disk.  It's important (mainly for security) that no two hash values
are the same and they need to be static per-object across process
lifetimes once assigned.

I could use the object's physical path for this purpose or some other
attribute with business meaning, but for performance reasons, it's very
undesirable to need to "fix up" the disk files when these (invariably)
change.

> IIRC the current implementation was meant more as a "first cut" - 
> Gregoire (who seems the main culprit), please correct me if I am wrong. 
> There was some exchange on the lists about CMFUid vs the concept of 
> UUIDs and I believe the outcome was that CMFUid does not claim to 
> generate UUIDs at all, just UIDs. I'm not sure if true UUIDs are even 
> in the scope of CMFUid.

I'm not sure there's much of a difference in cases like mine.  UUIDs
happen to claim to be "globally unique" but I really don't care whether
they are or not for my particular use; I just want them to be unique to
this Zope instance.  Any strategy that gets rid of the database write is
cool with me.

FWIW, the current implementation of CMFUid depends entirely on conflicts
to assure that no two threads get the same uid at the same instant. 
This is broken, at least under 2.7 (no MVCC) inasmuch as it depends on
BTrees.Length, which ignores read conflicts by design.  The current
implementation *will* dole out the same UID to two simultaneous
callers.  Subclassing Length is possible to make it respect read
conflicts and thus generate unique ids, but this will be a
performance-eating hotspot under 2.7 and perhaps under 2.8 depending on
how efficient MVCC is.

- C