db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: deletePersistent() automatically nulling out referring FKs?!
Date Thu, 06 Jul 2006 13:55:07 GMT
Andy Jefferson schrieb:
>> JDO2 did intend to disallow the behavior you describe.
>> Additionally, the metadata allows you to explicitly declare the
>> behavior of the FK on delete.
>> You could try explicitly setting the FK delete behavior to restrict,
>> and see what happens:
>>              <field name="b_1to1" column="b_1to1_FK"
>>                  persistence-modifier="persistent" >
>>                  <foreign-key delete-action="restrict"/>
>>              </field>
>> But even without this declaration, I think there is an issue with the
>> described behavior.
> Hi Jorg,
> lets be specific here, there are actually 3 situations :-
> 1. You have dependent-field set. This will delete the other object
> 2. You have a FK included in your metadata (which you haven't). This will 
> leave it to the DB to do the work and throw errors if necessary
> 3. You have nothing specified (so the JDO impl would have been allowed to 
> create no FK in the datastore if doing schema generation - fortunately for 
> you JPOX creates it for you thinking that you had simply forgotten). In this 
> situation you get the FK nulling. Its been like this since day one and gives 
> the smoothest result for the user ... they want rid of that record so it is 
> removed without affecting other records.
Concerning 3., well, you know, there's people making mistakes (like 
myself), and one might discover some day that relationship information 
had been deleted for years, and that this information is suddenly badly 
missing. Seriously, for some 1:n associations we were /very/ happy that 
internal errors occured in our application due to FK constraints being 
violated, as we forgot about certain relationships and that we never 
want that information to get lost (even though we allowed the user to 
try to delete it). So if that unspecified "SET NULL" or "remove from all 
relationships upon deletion" feature had existed for 1:n also, we would 
have been in trouble.

By looking at the code in DeleteRequest, it occurs to me that this 
particular code would be the perfect place to keep 1:1 assocations from 
degenerating into 1:n assocations, though!


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message