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

[Tres Seaver]

On Mon, 2003-05-05 at 14:33, Shane Hathaway wrote:
> 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.

Content designed for this use case will be less generally useful (see
below).  Descriptor-based majyk is not much help here, because there
won't be any good way to modify the policies hard-wired into the
descriptors.

> >>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

This will break for the same reasons that hard-wiring views onto content
classes do:  it is too hardwired, too majyk, and makes it impossible to
change the policy without modifying code.  I would wager that almost
*any* relationship which can't be modeled by containment (UML's
"aggregation") should be moved outside the responsibility of the content
class altogether.

> ...instead of this expression:
> 
> getRelationshipManager(individual, 'individual_children')

Views can supply adapters quite easily to their templates;  why wouldn't
it be simpler to let them do that?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com