Remove privately owned object: SQLException: cannot update ... to NULL

Question

I have a toplink descriptor called ToplinkRelationshipInfo which has a one-to-many mapping to a descriptor called ToplinkRelationshipAttribute. The mapping is privately owned and uses a foreign key from ToplinkRelationshipAttribute.info_id -> ToplinkRelationshipInfo.id. The ToplinkRelationshipAttribute has a one-to-one mapping back to the ToplinkRelationshipInfo.
The toplink generated Java source for ToplinkRelationshipInfo has a removeFromAttributes method:
public void removeFromAttributes(ToplinkRelationshipAttribute aToplinkRelationshipAttribute) {
     this.attributes.remove(aToplinkRelationshipAttribute);
     aToplinkRelationshipAttribute.setRelationshipInfo(null);
}When deleting/removing one of these attributes, if I simply call the above method and then call commit on the unit of work I get a SQLException:
Internal Exception: java.sql.SQLException: ORA-01407: cannot update ("WC"."WP_RELATIONSHIP_INFO_ATT"."RELATIONSHIP_INFO_ID") to NULL
I understand that the reason for this is because the removeFromAttributes method is setting the attribute relationshipInfo member to null, which is causing an UPDATE on the attribute record with null on the required relationshipInfoId.
As suggested in another thread I removed the line that sets the relationshipInfo member to null and I no longer get the exception.
For maintenance reasons I'd prefer to modify as little generated toplink code as necessary, so I'd rather not have to modify the remove method; otherwise I'll have to go through and modify all these types of methods anytime I generate new Java source.
So, how come toplink is generating the code that nulls these member variables if they have to be taken out later?
Is there a way to configure the workbench project so that it does not generate this code, or is it necessary to modify these methods each time I generate the Java source?
Thanks.

Answer 1

In a 1-m mapping the relationship is stored in the database by the foreign key of the 1-1 (m-1) back reference. In a typical 1-m relationship if you just remove the object from the collection it will not update the database unless you also set the 1-1 back to null, (as it will still be referencing the old source and the relationship will be out of synch).
In your case because the 1-m is privately owned and the target will be deleted, it does not need to have the 1-1 updated, so you are correct in removing the code.
In have logged an enhancement request internally with the MW to have this code improved for private-owned 1-m relationships.
In general the source code generation of the TopLink Mapping Workbench (or JDeveloper) is meant as a one-time generation for rapid prototyping, it is not required, and not two-way. Typically the object model will be used to provide application specific behavior, so will be maintained by hand after the initial prototype.