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

[Steve Alexander]

> I don't think I understand yet.  Why do you need an event framework to
> catch deletes?  Or is that a side issue?
> 
> One of the primary goals of ZODB is to be transparent.  Just write
> whatever Python code seems the most natural.  I can't think of any
> reason to avoid references to objects elsewhere in a tree.  (There's
> only one kind of reference in ZODB, so I think the modifier hard is
> unnecessary.)

This is true if you're writing a ZODB application.

In Zope 3, many things work based on how you traversed to get to an 
object. This aspect of "how you got to an object" is captured in its 
transparent context-wrapper.
Security and local services and looking up physical paths are all based 
(in some way or other) on inspecting the context-wrapper.


>>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.
> 
> 
> The discussion is a little abstract for me.  Do you have a simple
> concrete example of how you would do it in ZODB and how you would do it
> with an RDBMS?  Then we could try to understand why one is more or less
> natural.

I think this is a "managing content in Zope 3" question rather than an 
"indexing objects in the ZODB" question.

--
Steve Alexander