[Zope3-dev] zwiki: performance of findChildren()

Steve Alexander steve@cat-box.net
Wed, 23 Apr 2003 17:58:29 +0200


Jeffrey P Shell wrote:
> Well, then we get into the design issue of 
> Bob.receipts.receipt1.purchaser pointing back to Bob.  Actually, I just 
> don't know how to design for this scenario in the ZODB/Zope.  I've heard 
> that (at least, up until recently) maintaining hard persistent links to 
> objects elsewhere in the tree was a bad thing to do.

It is fine to do this in the ZODB.
It is not fine to do this in Zope 3 if you want the things that depend 
on security and "local context" to work.

If you're using ZODB and Global Component Architecture together then 
hard references should be ok.
If you're using Local Component Architecture, and/or locally defined 
security, then hard references are generally not a good thing.


> Even now - for 
> some reason, I'm scared of doing it (maybe it's just the lack of an 
> event framework to catch deletes, etc).

In Zope 3, you generally want an object in its context. That is to say, 
a context-wrapped object.


> I'm used to the relative ease of joins in SQL, yet in ZODB I often feel 
> rather constrained by the containment-only relationships (or have to go 
> out of my way to build catalog indexes, or do BTrees, path lookups, 
> etc).  I'm curious about moving out of this sphere, yet having the same 
> relative ease I get out of an RDBMS/SQL to be able to relate one thing 
> to another almost arbitrarily.

I'm excited about getting a relationships service into Zope 3.
I would like to see this kind of task made easy.


> Weak references are not a particular design decision.

I think you mean "location independent lightweight references".

You can use a hubId for that.


> I was just 
> thinking of a way of spelling "I'm interested in this object that I 
> don't contain".  Most likely, I want to have some sort of extra data 
> about that relationship/reference on the reference, and weakref just 
> came to mind as the shortest way of (apparently) incorrectly stating 
> that ;).

The relationships service, which will most often use hubIds, will be 
what you want.

--
Steve Alexander