[Zope-dev] Folderish or SimpleItem object types for structural content

[Dieter Maurer]

Martijn Jacobs wrote at 2005-12-1 01:06 +0100:
> ...
>If some conflict errors occure or for some reason the 
>objects are not indexed (correctly) or not updated, some important 
>information is not available for the user. I have experienced alot of 
>problems with unindexed objects, or not reindexed objects due to 
>'random' conflict errors'.

If "random conflict errors" lead to inconsistencies (object modified
but not reindexed), then they are very badly handled:

  Any exception that bubbles up to ZPublisher
  causes the complete transaction to be aborted: the effect will
  be neither an object modification nor a reindexing.

  If the object is modified but not reindexed in the context
  of a "ConflictError", then something must have caught
  the "ConflictError" -- a very bad thing...

  Unfortunately, unrestricted "try: ... except: ..." is not
  too uncommon. Zope some problems in this respect but
  meanwhile almost all places have been cleaned up.
  
But usually, when an object is modified but not reindexed,
it is the application (and not a "ConflictError")
that made the error -- it often forgets to call the "reindex".

> By making a complete hierarchical structure 
>using 'Object Managers', you can always assure that data is accessible, 
>and if the ZCatalog is not up to date, only the search results will not 
>represent the actual structure.

A much more important reason for this structure is acquisition (which
you will loose when you follow my proposal).

>>30.000 is not yet very impressing.
>>  
>>
>That's good to know. It's hard to say offcourse, but what is in some way 
>a 'limit' of the number of objects, for instance, if they all have to be 
>indexed? Indexing objects uses ALOT of CPU time for example... In which 
>amount of objects should you reconsider your design? (Speaking of a 
>'general' guideline)

Usually, you index incrementally (one object at a time).
The data structures involved when indexing a single object
behave logarithmically in the total number of objects.

Thus, I am not worried to have lots of objects indexed in the catalog.

-- 
Dieter