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