[Zope3-dev] Associations

[Gary Poster]

> From: Casey Duncan <c.duncan@nlada.org>
<snip>
> My suggestions, each of which is flawed in its own way go as follows:
>
> 1. <snip object reference discussion>
> 2. <snip UID discussion>

As I say at the end, I will put this up in the Fishbowl if I get
encouragement on it, and won't if I don't.  This is a feeler.

Repeating the "flawed" caveat Casey gave (i.e., I'm brainstorming, and have
been for a while), my thought to combine Casey's 1 & 2 is somewhat clunky
and simplistic.  It's just the best I've thought of.  I know Jeffrey and
Casey have probably seen something similar from me on the
ExplicitObjectReferences page, but this is a bit more fleshed out and a bit
different.  You would need all of the below.

1) an object registry, similar to what Ken proposed
(http://cmf.zope.org/rqmts/proposals/LinkObjects), that maps generated
integer UIDs to records comprised of (a) real object references (b) paths
and (c) probably metadata.  When an object is registered, the registry also
stores the UID in the object itself.  When asked to return an object by UID,
it does a path traverse to get the object, and then an aq_base identity
check against its own reference and a UID check against its own records.  If
a check fails, see error checks and catastrophe management, below.  When
asked to bless a copy/rename/move/delete (see 2 below) it would ask the
relationship registry (3 below) for permission, and if granted, update its
own records, and if denied, inform the object (perhaps merely by raising an
error, perhaps more gently).  (To support another of Ken's ideas that would
be very useful, the registry might need an API call to replace one actual
object with another, subject to the blessing of the relationship registry,
so that a UID could be kept in the relationship registry but changed to
point to a new place and object in the ZODB.  This would also allow some
interesting versioning-type usages.)  Another basic functionality of the
registry would be to just request metadata by UID, of course.

2) (either a completely reliable event channel or...) an associated mix-in
class for catalogable objects.  This would handle getting and setting the
UID, and wrap the standard copying/renaming/moving/deleting tasks with an
initial check-in with the object registry.  The object registry would have
an opportunity to reject the task, or to update itself if accepted (and
delete its own object reference, as appropriate).  I'm thinking of Zope 2.4+
too, not just Zope3, so I'd be interested in making sure that items 1, 3,
and 4 could work both with a Zope 2.4+ mix-in class and with a Zope3 event
channel of some sort.

3) A relationship registry that uses (a) the object registry UIDs and (b)
types and rules from the relationship type registry (4, below) to keep track
of relationships between objects, and submits potential relationship changes
to the relation type tool for blessing.  It would be convenient if this
subclassed a catalog as well.  It would also be nice if it could use
something like Casey's new intersection/union objects.

4) A relation type tool in which you can define relation types, constraints
etc.  Constraints probably could be pretty open-ended, with a basic
interface inviting you to roll-your-own, as well as some generic ones that
can be configured for the usual stuff.

This would provide the functionality we want, at least.

Error checks and catastrophe management:
Obviously, this design essentially relies on redundancy for object registry
catastrophe management.  In mapping a UID to an object, the object reference
would be the core data store, the path the next level, and the UID stored in
the actual object the lightest-weight info.

a) what if two objects have the same UID?  Not a problem.  They won't both
be registered in the object registry--the one with the matching path and
object reference is the right one.  If you want to register the unregistered
one, the object registry would do some basic checks, then overwrite the
conflicting UID.  [note: if it seems possible that we might want an object
to be a member of multiple registries, that would just be another design
decision; the basic of this design could remain]
b) what if the stored path is no longer valid?  That is, no object is there,
or a different object is there.  This is fairly bad, and the heart of the
redundancy stuff.  We at least have the possibility to slowly rebuild: it's
object search time through the ZODB.  You can search through the ZODB for
the UID, stopping when you have found an object with the UID and the same
object identity; you can also query the direct reference to the object for
data stored directly in the object and look through other catalogs for this
info; or you can present the user with the info and the problem, giving a
human the option to solve the problem quicker.

There are some other situations, but I think those two are the most
pertinent, ranging from the least problematic to (I think) the most
problematic.

One thing I ask myself is if storing the UID in the object really is useful.
It would be a convenience for querying the relationship registry, and would
save some lookup time I think...  It would be a definite attribute for which
to search in catastrophe b... So I think it is worthwhile, despite my
concerns.

Somebody tell me if this is worth pursuing and putting on a Wiki or
something.  If I am encouraged, I will; if I'm not, I won't.

Gary