On Fri, 01 Nov 2002 16:10:44 +0100 chrisf <chrisf@fagmed.uit.no> wrote:
Consider this,
I have a single Family python product. Family objects contains a hash of subfamily objects. Subfamily objects contain a hash of proteins. Protein objects contain a hash of amino_acids. Amino_acid objects contain a hash of atoms.
Since we are talking about a couple thousand proteins and a over a million atoms, I don't want to make anything under Family a proper zope object. I have seen ZopeDB bloat and its is not pretty.
If these are stored in a persistent object, then the bloat will be worse since a change to "any" subitem will require the entire record to be updated, which will consist of everything under the single persistent parent. Not to mention the fact that loading the object will load *all* of the subobjects into memory. This will likely make your application slow, memory hungry and db conflict ridden. IOW great pain will be inflicted... To keep things lighterwieght and avoid these issues, I would suggest storing these "subobjects" in BTrees, which are like dictionaries (which is what I am assuming you mean by hash), but use memory much more efficiently and handle conflicts much better. Then you can keep your lightweight object model and not kill the database. That said, with that many objects, your database will get big and depending on churn will need packing unless you use a non-undoing storage.
Yet because they are not proper objects, they can not be refered to on the URL or otherwise. ie http://whatever:8080/Family/Subfamily/Protein/Amino/Atom everything bounces back to the one true product Family
That is not a problem, a __bobo_traverse__ or __before_publishing_traverse__ hook on the parent can take care of the inner traversal. hth, -Casey