We're having problems with our enterprise application which is implemented using EJB 2. We use XDoclet to generate the interfaces and XML files. The database was created long before the application was developed.
We got on this project years ago for maintanance. It was not developed by us originally and we didn't get enough time and budget to write it from scratch or to migrate it properly to more recent technologies completely.
We have parameter records like EventType and data records like Event.
Strange enough, the EventType foreign key column in Event is nullable in the database.
When we remove an EventType instance, the EventType column in Event is just nullified.
Instead we would expect that the remove would be prevented by the foreign key database constraint that lies on the EventType column in Event.
Event refers to EventType with a foreign key constraint. We would expect a Constraint Violation because of the fact that you try to remove an EventType which is still refered from an Event.
Can anyone explain us what we should do about this?
I hope we do not have to check every relationship in the code itself while there are database constraints?
I know the EJB 2 spec isn't all that ... but we don't have another choice at this moment than using EJB 2.
We've had a similar problem with cascaded deletes.
There, a not null foreign key column to a parent record was tried to be nullified in the children because we deleted the parent. Ofcourse this was not possible due to the not null constraint.
Where Hibernate retains all SQL statements untill the session is committed or flushed, EJB 2 doesn't appear to behave the same where.
If you do some updates in Hibernate on a record and delete the record in the same transaction, Hibernate will only perform the delete. Not the updates.
EJB 2 appears to update the foreign key columns at the moment that a delete is called, where after he physically deletes the record after the ejbRemove() method.
I'm not sure if nullifying the foreign key columns is according to the EJB 2 spec, but it is the way JBoss has implemented the CMR behaviour in case of removal of a record.
We've found that a <batch-cascade-delete> (JBoss ONLY) option in XML will solve this by immediatly doing "delete where FK column = ..." instead of performing an update first.