Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 331692 - Can`t use custom add target query in OneToManyMapping
Summary: Can`t use custom add target query in OneToManyMapping
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Eclipselink (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 major (vote)
Target Milestone: ---   Edit
Assignee: Nobody - feel free to take it CLA
QA Contact:
URL:
Whiteboard: submitted_patch
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-02 11:41 EST by Ruslan Gainutdinov CLA
Modified: 2022-06-09 10:28 EDT (History)
2 users (show)

See Also:

Attachments
Patch for this problem (preview version, not well tested) (872 bytes, patch)
2010-12-02 11:44 EST, Ruslan Gainutdinov CLA 		tom.ware: iplog+
Details | Diff
Updated patch with test (6.08 KB, patch)
2010-12-21 14:49 EST, Tom Ware CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ruslan Gainutdinov CLA 2010-12-02 11:41:34 EST 
Build Identifier: 2.1.1.v20100817-r8050

Can`t use custom add target query in org.eclipse.persistence.mappings.OneToManyMapping.

I am trying to call setCustomAddTargetQuery(x) from my implementation of
DescriptorCustomizer.
However, the way org.eclipse.persistence.mappings.OneToManyMapping.initializeAddTargetQuery implemented my overrided addTargetQuery is not used.

Check for hasCustomAddTargetQuery is done AFTER addTargetQuery is initialized (ignoring any addTargetQuery set before).  

This obviously wrong, take a look at initializeRemoveTargetQuery.

Reproducible: Always

Steps to Reproduce:
1. Implement DescriptorCustomizer which calls OneToManyMapping.setCustomAddTargetQuery
2. Invoke JPA 
3. Observe NPE at StatementQueryMechanism.setCallFromStatement because standard addTargetQuery is not properly initialized
Comment 1 Ruslan Gainutdinov CLA 2010-12-02 11:44:29 EST 
Created attachment 184368 [details]
Patch for this problem (preview version, not well tested)
Comment 2 Tom Ware CLA 2010-12-03 09:07:38 EST 
If you haven't done so, it is likely a good idea to go through the mailing
lists or forums prior to posting these kinds of bugs.  The reason: There is a
good chance someone will be able to provide you with a reasonable workaround.
Comment 3 Ruslan Gainutdinov CLA 2010-12-03 09:10:14 EST 
> If you haven't done so, it is likely a good idea to go through the mailing
> lists or forums prior to posting these kinds of bugs.  The reason: There is a
> good chance someone will be able to provide you with a reasonable workaround.

Generally speaking - yes. But in this situation it is clearly visible bug. I would like to have fix for this problem, not workaround.
Comment 4 Tom Ware CLA 2010-12-03 09:25:40 EST 
Please vote for bugs you find important.  

We generally prioritize bugs with larger number of votes and with patches submitted by the community ahead of bugs that have neither of these things.

Often a workaround is a good way of allowing your application to work until your bug makes it way to the head of the priority queue.
Comment 5 Tom Ware CLA 2010-12-09 09:12:04 EST 
Setting target and priority.  See the following page for the meanings of these fields:

http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
Comment 6 Tom Ware CLA 2010-12-21 14:49:06 EST 
Created attachment 185666 [details]
Updated patch with test
Comment 7 Tom Ware CLA 2010-12-21 15:27:51 EST 
Checked in slightly modified changes and added test case to trunk

Reviewed by: Tom Ware - reviewed community-submitted-fix

Added test to EntityManagerJUnitTestSuite

Tested with JPA and Core LRG
Comment 8 Eclipse Webmaster CLA 2022-06-09 10:28:59 EDT 
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink