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
- Each category can have custom properties which can be 'inherited' by
the aqcuisition feature of zope.
This must be a funny classification scheme...
- 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)
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.
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.
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
30.000 is not yet very impressing.
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...
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.
Well thanks again for your thoughts, it helps in breaking patterns I'm
used too, let's reconsider it using some external input :)
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 -