[Zope3-dev] Associations

[Casey Duncan]

On Wednesday 23 January 2002 05:41 pm, Jeffrey P Shell allegedly wrote:
[snip relational frustration]
>
> 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?
>
> ..[1] http://dev.zope.org/Wikis/DevSite/Proposals/ExplicitObjectReferences
> ..[2] http://www.zope.org/Members/jshell/relations.jpg

I am faced with a similar problem in my own applications, which motivated me 
to write the proposal, which helped me, if nothing else, see how staunchly 
the current architecture resists this notion from several directions, unless 
you are willing to give up the original placefulness of the referent object, 
then its (fairly) easy.

My suggestions, each of which is flawed in its own way go as follows:

1. Simply store a reference to the task(s) from the invoice by storing them 
as attributes of the index. It won't matter whether the task is moved or 
"deleted", it will always exist in the invoice. The problem is that the task 
now has the invoice as its aq parent (when accessed from the invoice) and you 
must provide some interface in the invoice to allow tasks to be dissociated, 
otherwise they will live forever (or as long as the invoice does).

2. Assign a unique id to each task and catalog them. Store the ids in the 
invoices to associated them. Catalog the invoice task id lists as well. Then 
override manage_beforeDelete in the task (carefully so as not to upset 
catalog awareness) so that it checks the invoice catalog, and raises an 
exception if an invoice references the task. The disadvantage to this is the 
catalog overhead, and the fact that you will not be able to move (or rename) 
tasks after they are referenced. Also, you will have to handle copying of 
tasks and make sure the copies get assigned a new id, otherwise your unique 
id system gets hosed.

/---------------------------------------------------\
  Casey Duncan, Sr. Web Developer
  National Legal Aid and Defender Association
  c.duncan@nlada.org
\---------------------------------------------------/