[Zope3-dev] Re: ObjectHub should change data structure

[Gary Poster]

To reverse your email, Jim,

 > Or are you just thinking of churn *within* the hub?

Yes, that was the primary point of my email.

 From there, though, I hoped this sort of approach might spark another 
tack from which to approach the nasty event storms that the events your 
describe might generate.

What if, for instance, instead of a linked list, the object hub were a 
full-fledged directed acyclic graph, a la kjbuckets.kjGraph (actually 
don't know if this is acyclic) or something similar.  What if folder 
move/deletion events fired only a single event that were graph-based, 
lazily getting the full connected graph as needed for sub-objects?

The kind of use cases I care about for event listeners would like this. 
    For instance, let's say you delete a parent folder, and we have a 
relationship somewhere that wants to enforce relational integrity. 
(hands waving pretty wildly) This could simply be set 
operations--intersecting the deleted set with the set of objects in the 
right side of the relationships, and if there are any matches, finding 
the left side of these relationships and seeing if they are deleted 
also.  If any left hand side is not deleted, then raise a relational 
integrity error.

If these had been individual events, not only would this have been a lot 
more individual calls, but also we would not have been able (easily, at 
least) to determine if both sides of the relationship had been deleted, 
and thus accept (and even change our relationship's data to react to) 
the deletion.

I think moving these to set operations would be pretty powerful.

OTOH,

Phillip J. Eby wrote:
 > At 10:58 AM 6/27/03 -0400, Jim Fulton wrote:
 >>     o We'd sort of like to allow an object to be able to
 >>       have more than one parent.
 >
 >
 > Yeah, but we've been sort-of-liking this for what, 5+ years now?  Has
 > anybody actually used this yet?  Maybe it's time to call YAGNI on it.
 > (Maybe *way* past time.)

This, and the parent pointers, if we're willing to break another Zope 
mainstay, does feel like a better solution.

In several of our Zope 2 client projects, we have very strong use cases 
for having one object mounted in multiple places--except that, because 
of our data model and the desire to solve some of the very issues we're 
talking about here, we solve this with app-level object references that 
*seem* like we have the same object in many locations but in fact point 
to a canonical copy.  The actual object is only mounted once.  Each 
reference is another object that points to the original and sometimes 
even "adds value" by being a variety of special kinds of references.

The "mount once" would be a surmountable obstacle, I think, and would 
buy us a lot.

For instance, we might be able to use ZODB-based relationships, like 
Jeremy and Shane were talking about earlier, within Zope.  And yes, 
everything might feel a lot more Pythonic.

Gary