openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ezzio <>
Subject Re: [jira] Commented: (OPENJPA-236) No apparent way to generate all required SQL within a class derived from FullClassStrategy
Date Tue, 08 May 2007 14:35:32 GMT
Hi Abe,

Just to be clear, it is the BizB table that has the FK, and the BizA 
class that has the one-to-many relationship.

Whether the issue that I'm raising is a bug, an enhancement request, or 
a no-problem depends on what one expects to be able to accomplish by 
customizing a FullClassStrategy and assigning it as the class strategy 
for BizB with the OpenJPA Strategy annotation.

So far as I can tell, if one has BizB and BizA annotated to work with 
OpenJPA's support for an inverse-key mapping, and then one attempts to 
just alter the insertion SQL for the BizB class (without touching the 
domain model or the BizA mapping), one will find out that there is no 
way to do this with a custom FullClassStrategy for BizB.

Is this a problem? I think so. Assume one want to use stored procedures 
to replace all of the SQL that OpenJPA generates for a class. For this 
to happen, there must be one place where the SQL being generated to 
insert a BizB object can be overriden by the user. The obvious place to 
override the insertion SQL would be the customInsert method of the 
FullClassStrategy, but so far as I can tell, the two parameters passed 
into this method do not have the information required, even if the 
one-to-many relationship in BizA had a custom field mapping as you suggest.

It's possible that I'm stumbling around in the dark. If so, it would be 
great if you could shine a light on the issue.



Abe White (JIRA) wrote:
>     [
> Abe White commented on OPENJPA-236:
> -----------------------------------
> One-way inverse-key-based relations are not a typical case, given that they aren't even
supported in standard JPA.  You might need to use a custom field mapping in conjunction with
the custom class mapping.
>> No apparent way to generate all required SQL within a class derived from FullClassStrategy
>> ------------------------------------------------------------------------------------------
>>                 Key: OPENJPA-236
>>                 URL:
>>             Project: OpenJPA
>>          Issue Type: Bug
>>          Components: kernel
>>    Affects Versions: 0.9.7
>>            Reporter: David Ezzio
>>         Attachments:
>> FullClassStrategy has several optional methods for overriding OpenJPA's generation
of SQL. However, in a simple case, there is no apparent way to generate the required SQL within
a class derived from FullClassStrategy.
>> The model consists of two classes, BizA which has a one-way, one-to-many relationship
to BizB. The relationship is mapped with an inverse key within the BizB table.
>> The custom class strategy BizBMapping attempts to insert a BizB record and is able
to do so, provided that it is not contained within a BizA collection. Otherwise, the attempt
to persist a BizA with a contained BizB yields a SQL exception because OpenJPA generates additional
SQL that conflicts with the SQL generated within BizBMapping.customInsert. Even if OpenJPA
did not generate conflicting insert statement, there is no apparent way to get the value for
the A_ID column within the BizBMapping.customInsert method.
>> This issue is critical for users who want to substitute their own SQL (such as calls
to stored procedures) for all of the OpenJPA generated SQL.
>> Synopsis of the output log:
>> INSERT INTO BIZB (ID, INFO) VALUES (?, ?) [params=(String) B22047141, (String) random]
>> INSERT INTO BizA (id, info) VALUES (?, ?) [params=(String) A32968849, (String) random]
>> INSERT INTO BizB (A_ID) VALUES (?) [params=(String) A32968849]
>> SQLException: Column 'ID'  cannot accept a NULL value. 

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.

View raw message