Re: RE: [Plone-developers] Plone 1.1 - TODO

Am Sonntag, 8. Juni 2003 19:54 schrieb 
sean.upton-lttx/tDbukJF6kxbq+BtvQ@xxxxxxxxxxxxxxxx:
> 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

Your rigth, It is 10000 not 10000.
Neverthelesse I did run the following loop:
x = {}
while 1:
  x[int(time.time() % 10000)] = 1

after running five minutes on a moderately fast machine it had produced only 
335 entries in the range from 7034 to 7438.

I intended to batch create a couple of tousand users with each an index_html 
in their home folder. This is just not possible with the current 
implementation.

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

This sounds very good

Robert

> 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.
> _______________________________________________
> Archetypes-devel mailing list
> Archetypes-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/archetypes-devel

-- 
mit freundlichen Grüssen

Robert Rottermann
www.redCOR.ch



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