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

[Ken Manheimer]

On Mon, 5 May 2003, Shane Hathaway wrote:

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

Ok - providing for relationships in standalone applications that use
ZODB...

> Ken Manheimer wrote:
> > 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.

If you're saying it should be an option to do it that way, then i'm
fine with that.  (That's what i intended for the relationship manager
example that mediated access to relationship info stored in the
objects.)  If you're saying all relationships would always need to be
expressable that way, then i would object.  I think it would be too
intrusive - it requires that objects are changed for any kind of
relationship in which they participate.  Plus, the relationship name
may conflict with existing attributes on objects you want to
participate in the relationship.

> > Am i missing something, oversimplifying?
> 
> You're just exploring a different aspect than I was referring to. :-)

The overriding thing is that i see the third-party relationship
management scheme as allowing for the first-party containment of
relationship data, among other arrangements, while i see requiring the
first-party containment as preventing the things i need to do with
other kinds of arrangements. and unnecessarily burdening the
implementation of the objects.

-- 
Ken
klm@zope.com