On Tue, 2003-11-25 at 10:19, Paul Winkler wrote:
On Tue, Nov 25, 2003 at 09:17:03AM -0800, Dylan Reinhardt wrote:
Using my data model, let's say Aida has a "piece_composer" property of 'Verdi' and there is a Verdi object in the Composers folder, a peer to the Pieces folder. To render useful composer information in a Piece object's interface, all you need to do is something like:
-----
<B>Composer</B>: <dtml-call "REQUEST.set('compsr_obj', _[piece_composer])"> <a href=Composers/<dtml-var "compsr_obj.getId()">
<dtml-var "compsr_obj.title"></a>
And you're done. Each piece displays its composer and links to the composer detail screen. Data management is practically transparent.
The more interesting problem is to find all pieces composed by Verdi.
Which is why my original suggestion included caching reverse references. Splitting a pair of "foreign keys" across two objects is not much more difficult than (or conceptually much different from) storing a pair of foreign keys in a third table/object. The important thing is that both elements of the pair be managed by a *single* set of processes. If the process that updates one side is the only process that updates the other side, you won't have to worry much about orphaned references. A small amount of validation can virtually eliminate the problem. Having a single process strongly implies using an *interface* for managing references... you don't want to simply expose your references in a text field. I recognize that this practice is unconventional, so I won't go very far out on a limb defending it. But it has worked very well for me and this list is all about sharing stuff that works well.
Fortunately, I can give the solution in one word: ZCatalog.
Sure, that works too... primarily by doing something very similar with a far greater amount of overhead. :-) Dylan