Andy Jefferson schrieb:
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.
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"
But even without this declaration, I think there is an issue with the
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.
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!