Hello Dieter.

This must be a funny classification scheme...
Well, I wanted to have the discussion to be general about this thing because I can imagine that this issue has been some point of discussion before, among others, but I will be more specific to explain : - The structure will have categories within categories. (hierarchical categories) - Each category can have custom properties which can be 'inherited' by the aqcuisition feature of zope.
- Within the categories you have "object's".
- Each "object" can derive his properties through acquisition, or have their own properties (or override the acquisiton properties) - Each "object" will have "item groups", with their own properties / files / comments / etc. - Each "item group" will contain "items", each item will have properties, but also can have properties derived through acquisition from categories and objects : so these "items" will all have different properties, depending in which category they exist.

With this rules I was thinking about the next structure :

Category (Object Manager, within other Categories) -> Object (Object Manager) -> Item Group (Object Manager) -> Item (Simple Item)

But anyway: I have a completely different strategy for you:
lets see whether you will like it.

You do not materialize the classification scheme at all but you
have only your leaves (let's call them "object"s).

Each object has its classification as an attribute, say "category".
A "category" thus has the form "topic/subtopic/subsubtopc/...".

You index the "category" with a PathIndex (I would recommend
my "Managable PathIndex") and use canned searches (so called "topic"s)
the recreate the classification structure via searches (if needed).

If you do the last step (use "topic"s for the complete recreation of the
classification structure), then the number of objects will
not decrease (what formerly was a classification folder is now
a "topic"). But the new structure is much more flexible.
You can now assign different categories (say along different
dimensions) to your objects and will get different hierarchical (topical)
views on your object set.
I have been thinking about this kind of structure to use for this specific project. But there is a problem that occures (too) often (in my experience) with this approach. By doing this you really are depending on the ZCatalog : 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'. 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.

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)

You should take care to use the correct folder implementation, however.
As soon as a folder is likely to have more than a few dozen of objects,
you should use a "BTreeFolder2" rather than a normal folder.
I've used the BTreeFolder2 before for a single folder containing large number of objects, and indeed, it's really boosting the perfomance a lot...

Well thanks again for your thoughts, it helps in breaking patterns I'm used too, let's reconsider it using some external input :)

Kind regards,


Martijn Jacobs
Four Digits, internet solutions
e-mail: [EMAIL PROTECTED] | web: http://www.fourdigits.nl
tel: +31 (0)26 44 22 700 | fax: +31 (0)84 22 06 117

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to