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

[Shane Hathaway]

Ken Manheimer wrote:
> On Mon, 5 May 2003, Shane Hathaway wrote:
>>I'd like to mention that relationships would be quite useful in pure 
>>ZODB applications as well.
> 
> 
> Could you say more about that?  Are you thinking about provisions to
> facilitate ZODB operation, or rather, other applications which use
> ZODB and which would want to do similar high-level relationship
> queries?  I think i've seen mention in this thread about the former,
> though i suspect that kind of concern would call for different
> mechanisms than application-level stuff...

I'm speaking of the latter--allowing people to write ZODB applications 
that store and query relationships, without using the Zope 3 component 
architecture.  The former concern, that of changing the way ZODB 
operates, was mentioned in connection with Ape.

>>There is a need for both kinds of access.  In a genealogy program, it is 
>>natural to ask an individual for a list of children.  Yet because there 
>>are often conflicting sources of information, you can't just store the 
>>children as subobjects of the individual.  The individual should 
>>delegate the management of its list of children to a centralized 
>>database that layers multiple sources transparently.  (Whoa, that would 
> 
> 
> I don't see that layered arrangement as fundamentally different from
> other relationships.  Instead, i see it as a job for a special
> relationship manager, which would plug into the relationship
> management service.

Perhaps, but I'm talking about a more mundane detail.  Specifically, I 
believe it is important to be able to use this expression:

individual.children

...instead of this expression:

getRelationshipManager(individual, 'individual_children')

Until it can be spelled in a simple way, relationships in Zope/ZODB 
won't be complete.

>>be cool.  Why didn't I think of it like that before? ;-) )  But in the 
>>case of a plumber directory, it makes a lot more sense for the 
>>application to skip the indirection and look at the plumber directory.
> 
> 
> It's just a simpler relationship manager.
> 
> I even see having relationship managers that mediate for relationship
> information stored on the objects, themselves, if that's where it's
> best for the information to be stored.  These mediators could provide
> additional value by, eg, implementing relationship-info caching, as
> well as filling the plug-point for the relationship service.  I
> wouldn't expect typical Zope applications to store relationship info
> this way, but the option would be there.
> 
> Am i missing something, oversimplifying?

You're just exploring a different aspect than I was referring to. :-)

Shane