DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Areg Beketovski
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

Explicit parameters in JDOQL subquery do not work

Created: 14/May/10 08:48 PM   Updated: 24/May/10 03:43 PM   Resolved: 18/May/10 02:19 PM
Component/s: Queries
Affects Version/s: 2.1.0.m2
Fix Version/s: 2.1.0.m3

File Attachments: 1. Zip Archive (3 kB)
2. Zip Archive (2 kB)

Datastore: Microsoft SQL Server

 Description  « Hide
This used to work in v2.0.4, now it just throws "Variable <varName> is unbound and cannot be determined" exception at

Seems like passing "subquery.explicitParameters" to JDOQLCompiler for the subquery makes it work:


                if (NucleusLogger.QUERY.isDebugEnabled())
                    startTime = System.currentTimeMillis();
                    NucleusLogger.QUERY.debug(LOCALISER.msg("021044", getLanguage(),
                JavaQueryCompiler subCompiler = new JDOQLCompiler(ec.getMetaDataManager(), ec.getClassLoaderResolver(),
                    subquery.from, subquery.candidateClass, null,
                    subquery.filter, getParsedImports(), subquery.ordering, subquery.result,
                    subquery.grouping, subquery.having, subquery.explicitParameters, null);
                subCompiler.setLinkToParentQuery(compiler, subqueryDefinition.getParameterMap());
                QueryCompilation subqueryCompilation = subCompiler.compile(parameterValues, null);
                if (QueryUtils.queryReturnsSingleRow(subquery))

but need to additionally pass all the subquery parameter values to the main query upon executeWithMap(), which was not required in 2.0.4 version. Unfortunately " subCompiler.compile(subqueryDefinition.getParameterMap(), null);" does not help - generates subquery with "NULL" values, looks like parameterValues is used to initialize subquery parameter values somewhere.

Andy Jefferson added a comment - 15/May/10 08:20 AM
Any problem needs to be demonstratable. In this case a test case for our suites (e.g test.jdo.datastore)

Andy Jefferson made changes - 15/May/10 08:20 AM
Field Original Value New Value
Priority Major [ 3 ] Incomplete [ 6 ]
Areg Beketovski added a comment - 17/May/10 05:31 PM
Please see attached the testcase demonstrating the issue. Testcase was run against 2.1.0-m3-SNAPSHOT jars from 17-May-2010 02:32 where it fails and against 2.0.4 jars where it works.

Areg Beketovski made changes - 17/May/10 05:31 PM
Attachment [ 11170 ]
Andy Jefferson added a comment - 18/May/10 07:02 AM
Except that you are misusing the "parameters" argument in the addSubquery() call. This is to bind to expressions in the outer query (whereas you think its for passing in the values of the parameters in the subquery ... which is isn't).
Neither the javadocs nor the spec say anything about using values out of that Map as the values of parameters for the query.
<javadoc>@param parameters the expressions from the outer query to bind the parameter in the subquery</javadoc>
The parameter values for the query (and any subqueries) are input via execute(). And no it doesn't matter if "legacy" allowed you to get away with that; that doesn't mean it was "supported".

Passing the subquery.explicitParameters into the subquery compile stands though.

Areg Beketovski added a comment - 18/May/10 02:10 PM
Fair enough, please see attached the updated testcase. This already works with trunk version of

Areg Beketovski made changes - 18/May/10 02:10 PM
Attachment [ 11172 ]
Andy Jefferson added a comment - 18/May/10 02:19 PM
Marking as fixed then

Andy Jefferson made changes - 18/May/10 02:19 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 2.1.0.m3 [ 10943 ]
Resolution Fixed [ 1 ]
Andy Jefferson made changes - 24/May/10 03:43 PM
Status Resolved [ 5 ] Closed [ 6 ]