Ok, so I've done a lot of searching on these forums and other areas about the issues with foreign key constraints, jboss, and the j2ee spec. I would like to first, make sure I'm not misunderstanding something, and second ask how people have circumvented this "feature".
>From what I understand the j2ee spec specifies that foreign key constraints are not >adhered to when the orginal object is deleted? Instead, it bypasses the RDBMS and >first sets the child foreign key to null then removes the parent entity. This is >shown below: | 13:37:41,628 INFO [CMSLogger] PageManager: Remove contentManagementUser by ID: 201 | 13:37:41,635 DEBUG [ContentManagementPath] Executing SQL: SELECT path, rights, fk_content_management_user_id FROM content_management_path WHERE (pk_content_management_path_id=?) | 13:37:41,639 DEBUG [ContentManagementPath] Executing SQL: UPDATE content_management_path SET fk_content_management_user_id=? WHERE pk_content_management_path_id=? | 13:37:41,641 DEBUG [ContentManagementPath] Rows affected = 1 | 13:37:41,641 DEBUG [ContentManagementUser] Executing SQL: DELETE FROM content_management_user WHERE pk_content_management_user_id=? | 13:37:41,645 DEBUG [ContentManagementUser] Remove: Rows affected = 1 | 13:37:41,646 INFO [CMSLogger] PageManager: ContentManagementUser ID: 201 removed | What your seeing here is jboss finding the child of the relationship, setting the fk to null and removing the requested object. This, of course, orphans the child. (Just to be clear, the ContentManagementPath is an EJB and this functionality is built into JBoss 3.2.1 (tried 3.2.3 also) CMP2.0, not my app). I haven't read the spec myself and would really rather not if I could avoid it, hehe. But am I correct in understanding that the above is "appropriate"? Ok, assuming I am correct above, I only see a couple options, and they're all doodie. I can set all foreign keys in the application to NOT NULL which would blow an exception which I could catch and handle when jboss tries to pull this stunt. Unfortunately, it concerns me a bit that there may be other unforseen effects of the NOT NULL option. Another option is to duplicate the functionality in my application the the RDBMS (PostgreSQL if you're curious) already provides and check all my dependencies manually (*P U K E*) and throw my own SQLDependencyException before I allow the Remove operation to take place. Are there other options I've missed? What have you done to work around this? Any other advice? Unfortunately, this is a mature application which is in production and we are committed to (and have been mostly happy with) JBoss, so there is a feeling of desperation with this. Finally, and feel free to ignore this part if you wish, but me and my folks are astounded at this and can not figure out for the life of us why the spec would specify that it is ok (or even manditory) to destroy database relational integrity by circumventing very VERY basic db protection functions. Also, why would the spec support the creation of foreign key constraints if it subverts them? I'm not flaming, I promise. . I just can not for the life of me even take a decent guess at this logic and really am curious. Thanks for any information! Gerald Anderson View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3835788#3835788 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3835788 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
