Mostly the rationale is that I was unsure of all the consequences of changing the 
simple
attribute while other object relationships may exist due to the foreign key.  For 
example
object A object may be
in a collection of object B due to the foreign key attribute A.b.  I did not want to 
add
such integrity checks to A.setB_ID or more correctly did not have the 
time/intelligence to
make sure the relationships remained valid.

But as the design developed, it became apparent that it would be too expensive to 
maintain
complete integrity of the object relationships and since the normal use of the om/peer
objects is to provide a thin object layer on top of a relational database, I have opted
instead to leave more in control of the developer.

For example it could be possible to add A to a collection in B, remove A's reference 
to B,
then use B's collection which will still show A as belonging in the collection.  So the
Exception disallows such an operation.  But then as you see I went ahead and gave a 
way to
accomplish the relationship mismatch anyway.

I did something along the same lines in A.getB() where I think the most OO and 
foolproof
practice would be to make sure that A is then represented in any appropriate 
collections
in B.  Because one could do something like 
B b = a.getB()
loop over b.getAs()
        print oneOfTheAs.getName();
endloop

And in a perfect OO model "a"'s name would show up in the list.  However the coupling
would lead to
a lot of database activity that is could be irrelevant to what is desired in another
situation. (I should say a's name will probably show up in the list, it will just be
another instantiation a' that is included in the collection.) And a == a' would give
false, though a.equals(a') should give true.

All this is to say, feel free to make it easier. :-)

Sean Legassick wrote:
> 
> John,
> 
> What is the rationale behind disallowing setting of a foreign key when
> an associated object has been retrieved? Sometimes even after retrieving
> the associated object by object, I'd then like to set a new association
> by ID rather than by retrieving the object with that ID and doing it
> that way.
> 
> The patch below may not be the 100% correct way to alter this, but I'd
> like to see a change something like this:
> 
> (BTW this is my first issue with the way complex OM code works, and I've
> been doing quite a lot with it...)
> 
> Index: Object.vm
> ===================================================================
> RCS file: /products/cvs/turbine/turbine/conf/torque/templates/om/Object.vm,v
> retrieving revision 1.26
> diff -u -r1.26 Object.vm
> --- Object.vm   2001/02/08 02:43:57     1.26
> +++ Object.vm   2001/02/14 15:13:43
> @@ -75,11 +75,7 @@
>      #else
>          #set ( $varName = $tstrings.concat(["a", $tblFK.JavaName]) )
>      #end
> -        if ( $varName != null && !${varName}.isNew())
> -        {
> -            throw new Exception("Can't set a foreign key directly after an "
> -                + " association is already made based on saved data.");
> -        }
> +        $varName = null;
>    #end
> 
>    #foreach ($fk in $col.Referrers)
> @@ -161,7 +157,6 @@
>      private $className $varName;
>      public void set${pVarName}($className v) throws Exception
>      {
> -        $varName = null;
>     #foreach ($columnName in $fk.LocalColumns)
>      #set ( $column = $table.getColumn($columnName) )
>      #set ( $colFKName = $fk.LocalForeignMapping.get($columnName) )
> 
> --
> Sean Legassick
> [EMAIL PROTECTED]
>       Czlowiekiem jestem i nic co ludzkie nie jest mi obce
> 
> 
> 
> ------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?:           [EMAIL PROTECTED]


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to