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

[Ken Manheimer]

On Mon, 5 May 2003, Shane Hathaway wrote:

> Ken Manheimer wrote:
> > This requires something like the event service and object hub to
> > reliably maintain the relationship info.  It's no coincidence that
> > Zope3 has them.  They're generally useful for doing kind of thing -
> > and in fact i think my ruminations on OrganizationObjects had
> > something to do with prompting those services.
> 
> 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...

> Yes!  RDF is a serialization of relationships.  Each RDF triple maps an 
> entity to a role in an entity-relationship diagram.  RDF fits so well 
> with general relationships that I sometimes think that RDF should stand 
> for something like "relationship data format" rather than "resource 
> description framework".  RDF's generality, OTOH, makes it hard to 
> understand at first.

The spiffy thing about RDF's "resource" is that it includes the
assertions as well as the targets of the assertions, so you can make
assertions about assertions.  I consider it an incidental, but
significant, advantage that the word avoids the relational-algebra
connotations of "relation", and even "relationship".  IIUC, relational
algebra is about rectangular-table math, with a lot of mathematical
baggage that we don't need or want to incur.

> >Chris Withers:
> >>If you wanted to know what someone was working on, would you ask them or ask
> >>their mother?
> > 
> > 
> > I don't see how your question is relevant.  ?
> > 
> > At least, the kind of thing that concerns me is more along the lines
> > of this question: "If you wanted to call a plumber, would you go to
> > everyone in your city to ask them if they do plumbing, or would you
> > look in a directory?"
> 
> 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.

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

-- 
Ken
klm@zope.com