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. 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 Any clues: Session variables ? Operator overloading __call__, __getattr__? Aquistion ? Any help greatly appreciated Chris :)
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
On Friday 01 November 2002 3:10 pm, chrisf 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.
You need to get the granularity right. Too big is just as bad as too small. ZODB performs alot of operations at the level of individual persistent objects. If each object is too big, then these operations become inefficient. One of the nice things about ZODB is that it is easy to make an object persistent by just adding the 'Persistent' base class. I suggest you experiment.
Yet because they are not proper objects, they can not be refered to on the URL or otherwise.
There is no such restriction. URL traversal occurs independantly of the persistence characteristics of the objects being traversed. I think you have some other bug.
chrisf writes:
... 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.
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 When a relational database it adequate to store your data (i.e. it is highly structures, essentially a collection of attribute values of simple type), then you can put them in a relational database and access them with ZSQL Methods.
The direct traversal facility of ZSQL Methods (see "Advanced" tab; maybe the Zope Book) can make database records URL accessible. The "Brain Class" facility (or acquisition) can may ZSQL wrapped database records have interesting behaviour.
Session variables ? No.
Operator overloading __call__, __getattr__? Maybe. Aquistion ? Not bad.
Dieter
participants (4)
-
Casey Duncan -
chrisf -
Dieter Maurer -
Toby Dickenson