openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: SQL ordering and foreign key constraints
Date Wed, 25 Apr 2007 00:12:15 GMT
Sounds like a bug. Bugs are definitely something that we're interested
in, especially when they come with patches.

In fact, new features and enhancements are also especially welcome when
paired with patches.

Can you open a JIRA issue for this and attach the patch there?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Reece Garrett [mailto:RGARRET@co.pierce.wa.us] 
> Sent: Tuesday, April 24, 2007 3:59 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: SQL ordering and foreign key constraints
> 
> Hello,
>  
> I came accross a problem where my foreign key constraints 
> were being violated because of the SQL insertion order during 
> merge operations. I am aware that OpenJPA does not do any SQL 
> re-ordering to avoid violating foreign key constraints, 
> however, it was trivial to make the needed changes in 
> org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. 
> In the case of a row insert I iterate over all foreign keys 
> defined in that row. If I find one that  is new (needs to be 
> persisted), has an auto-assigned primary key, and cannot be 
> null (nullable=false)  then I move the row to the bottom of 
> the list so that it will be inserted after it's foreign keys. 
> In the current code that determines whether a later update is 
> needed for the foreign key I added a check to see if the 
> foreign key's state manager had already been flushed.
>  
> The net effect is that the insertion order will stay the same 
> unless a not-null constraint on a to-be-inserted foreign key 
> exists. In which case, that row will be inserted after the 
> foreign key it depends on.
>  
> I am interested in submitting my changes as a patch but 
> having seen comments that suggest this is not something on 
> OpenJPA's roadmap am wondering if there would be any interest.
>  
> -Reece
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message