[Zope-CMF] Re: cmfuid

[Tres Seaver]

Chris McDonough wrote:
> 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.

You don't need to, if you store the hash key used to locate the file on 
the object itself.  You should then plan to index them, in order to 
traverse back from the file to the ZODB object. ;)

BTW, the performance hit of moving an inode from one directory to 
another within the same filesystem is inconsequential when compared to 
the other costs you are going to incur when you move placeful content.

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

You are worried about adding a single entry in a btree-bucket when 
creating all the other crap associated with a new content object in the 
ZODB?  Really?

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

That is a different problem.  The approach should probably do something 
like the RID-generation stuff in the catalog, which doesn't rely on 
write conflicts to avoid collisions.

I don't think you want a purely probabilistic / heuristic solution, but 
I could be wrong (feel free to ding me for a beer, if so).

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com