I recently encountered the same problem.
The EJB spec requires the relationship fields be set in ejbPostCreate.
However, I'm not sure making the referencing column nullable violates referential integrity rules. The ANSI SQL 92 spec seems to allow that a foreign key constraint referencing column need not be null. We all know about one cascade operation being to allow "cascade deletes" of the child rows in the referencing table. However, another operation is to allow "cascade nulls" into all the foreign key columns. This at least implies the SQL spec accepts the notion of nulls in referencing columns.
I'm with you though. I'd rather my fk fields be set to not null as a rule.
If you don't want to make your fk fields in the database nullable, then one suggested approach is to create a CMP virtual field (CMF) on the referencing bean corresponding to the fk field in the table. Then, in ejbCreate, set the CMF value and in the ejbPostCreate method set the CMR field.
There is a mechanism within Oracle to defer constraint checking until the transaction is commited. I think it is the deferred key work on your constraint creation command. You should ask your dba, or check the oracle documentation for more information.
This does not compromise your integrity.
Yes, thanks...that worked fine.
I added a constraint to the table checking the foreign key field was not null with the DEFERRABLE INITIALLY DEFERRED parameters.
Thus the constraint was only checked at commit time and the bean was created successfully.
The default with Oracle is to check immediately, so this has to be done for all foreign key not null fields.
Cheers Jack for your suggestion. Mapping the foreign key CMR fields to CMP fields, and populating them in the ejbCreate also works, but requires a code change. Hence Oracle solution (for me) is the tidiest.