[Zope3-dev] Associations

[R. David Murray]

On Wed, 23 Jan 2002, Jeffrey P Shell wrote:
> A frustrating thing about designing in Zope/ZODB is the difficulty of doing
> non-containment relationships.  While paths *can* be used to refer and get
> to other objects within Zope, the folder-like nature of Zope makes it
> natural to do various move operations (cut/paste, rename) that end up
> invalidating any path reference to a particular object.  This is a common

Personally, I am starting to feel that the hierarchical organization
of the OFS is a mistake for many projects <wry grin>.

> deletion).  In Zope, this is hard, especially where move operations are
> common.  In the projects/tasks/invoices scenario, after a certain period of
> time projects might get moved to an Archives folder.  The billing invoices
> still need to keep their references to the tasks in that project.

Perhaps I'm being naive, since I haven't really developed any
*large* OO systems yet, but it seems to me there is an easy answer
to this particular example, and indeed this class of problem.  Once
the project is created, don't allow it to be moved.  Instead of
"moving it" to an archive folder, set an 'archived' flag on it.

> >From the perspectives of both a component developer and an application
> integrator, how might the references be updated so that a business rule like
> "once a task is referenced by an invoice, that task must *always* be
> reachable from the invoice" can be enforced?  Are there any existing
> notions?

I know it's kind of abandoned now, but ZPatterns encouraged a style
of programming that it seems to me addresses these kind of issues,
since it abstracted the link between access to data and where that
data was stored.  So in ZPatterns you'd have a projects specialist,
and the id used to access a project would be enough to retrieve
that project forevermore from that Specialist.  Behind the scenes
you could store and fetch the project data from wherever.  And if
a different part of the app required a different view of the data,
it was easy to layer that in, too.  And by having a "lowest layer"
specialist that provided the ultimate interface to the data, you
had a place you could enforce certain data integrity constraints.

Since ZPatterns is just a tool to make using certain OO design
patterns easier, you can do this kind of thing in zope without
ZPatterns by ignoring the OFS.  If you've got data whose movement
would be a problem, don't allow it to be moved.  Store all the
objects in a btree, say, and provide an API to the rest of your
app for getting those objects.  It seems to me like an 'archive
folder' should be a UI implementation detail, not a data storage
pattern.  It also seems like this should apply to most other
situations where the "location" of *content* would otherwise seem
to cause issues.  Using Cataloged Ids just seems like a bass
ackwards way to provide a storage independent interface to
a what should be a unified collection of data...

--RDM