RE: [Plone-developers] Plone 1.1 - TODO

I've posted this response over to archetypes-devel instead of
plone-developers.

> References as they are done in the actual version are very 
> weak (not more than 
> 1000 objects with the same name, which breakes for index_html 
> in the members 
> folder) and do scale VERY poorly.
> I filed a bug for this.
> Robert

I thought this was 10k not 1k for each object with the same zope id?  Still,
it is a limit that might be an issue _IF_ you have a system where there are
likely to be a lot of items with the same id.  Ideally, you try to globally
avoid the overlap of ids, but this obviously cannot be a solution to
index_html?  

The immediate fix for this is easy - just change the size of the random
number pool in _genId() to a larger number.  This should not break backward
compatibility with old uids, I think.  For example:

>>> import time
>>> i = int((time.time() % 1.0) * 10000)
>>> i
8646  #won't be larger than 10k
>>> i = int((time.time() % 1.0) * 1000000)
>>> i
528131  #won't be larger than 1Million

Another thought: Right now, I'm working on a patch to ReferenceEngine that
(a) replaces PersistentMapping with OOBTrees, (b) migrates existing
PersitentMapping reference attributes to OOBTrees to support upgrade, and
(c) adds methods for aggregate ref/bref querying (putting proper
names/labels on brefs via lookup table).   For the future: In approaching
(a) I was thinking about how BTreeFolder2 does its UID generation: random
ISN and sequential IDs afterward.  This is a bucket/thread affinity and
conflict-minimization mechanism, as it is likely that the ISN that each
thread/client picks will be in a different bucket than other threads
updating the btree and each thread tends to stay within its own btree.  This
may be a YAGNI thing for references, but I suppose there could be a
high-write situation on a site where all content heavily use references and
there are high-frequency updates. 

Sean


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.