> An interesting thought here: Given that the link tables must (by
> definition) have a pk of the combined pk's of the related objects, a
> given pair of objects A,B can only ever have one link record if db
> integrity is to be maintained. If we take the fix to the first problem
> (above) to the natural conclusion, we simply do not allow the same link
> to be created twice (we ignore the second registration because it's
> already been done). Then the setReverse clause of the if-statement
> around the register operation is unnecessary.
>
> Can anyone see an issue with this resolution? It's not quite as
> efficient, but is more correct.
>
> (Oh, and this will have to apply to removeToManyTarget too)
>
I believe, you are quite right and this is the best way to proceed.
Everytime addToManyTarget is invoked we can check both A->B and B->A
variants and allow only one registration per {A,B} pair. When efficiency is
important one can manually handle this kind of relationships without
flattening them.
This archive was generated by hypermail 2.0.0 : Tue Feb 04 2003 - 16:17:10 EST