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)

Key: NUCCORE-701
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Guido Anzuoni
Votes: 0
Watchers: 0

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

Bad parsing when multiple subqueries in JDOQL/JPQL single-string query

Created: 21/Apr/11 07:09 PM   Updated: 09/May/11 09:58 AM   Resolved: 22/Apr/11 03:20 PM
Component/s: Queries
Affects Version/s: 2.2.3, 3.0.0.m3
Fix Version/s: 3.0.0.m4

File Attachments: 1. Java Source File (24 kB)

 Description  « Hide
The problem is cause by the replace of the original subquery with stringContent StringBuilder that alters the length of the resulting string.

Sort Order: Ascending order - Click to sort in descending order
Guido Anzuoni added a comment - 21/Apr/11 07:10 PM
Damn.. 3.0.0-m4

Andy Jefferson added a comment - 21/Apr/11 07:26 PM
No, 3.0.0.m4 is not released so a bug cannot exist in that, so marking as 3.0.0.m3.
As per JIRA, "NUCJPAQUERY" is for the JPA Criteria annotation processor, and don't think you're referring to that

Guido Anzuoni added a comment - 21/Apr/11 08:08 PM - edited
No in fact, it is single string jpql and I'm referring to
I'm trying to fix but subquery always turns to be
someentity.member = (..)
even if the original statement is
someentity.member in (..)
keep on debugging.....

OK some findings.
I am able to parse a query like
select a from A a where a.number in (select b.number from B)
into a
select a from A a where a.number in (DATANUCLEUS_QUERY_1)
this due the presence of parenthesis around DATANUCLEUS_QUERY_1
is compiled into an assignment node instead of an IN node.
I have tried to tweak the filter passed to the compiler removing braces and it works

Guido Anzuoni added a comment - 21/Apr/11 09:16 PM
I have modified the parser so that it correctly "tokenize" into subqueries.
As it is, it preserve any character present in the statement (even the braces
around subquery).
I don't know why, but in this way the compiler ignores the IN keyword present
into the statement assuming an assignment instead

Andy Jefferson added a comment - 22/Apr/11 09:24 AM - edited

Guido Anzuoni added a comment - 22/Apr/11 01:38 PM
A query with two (not nested) subqueries is missing and it is my usecase.
I will add one.
Anyway IF the pb is confirmed, is it correct that the compiler assumes a IN or = operator depending on the braces around
the name of the subquery ?

Andy Jefferson added a comment - 22/Apr/11 03:14 PM
SVN trunk of JPQLSingleStringParser (now) works on my (added) test with multiple subqueries. Same problem present in JDOQL actually.

I get no such conversion of "IN (subquery)" to "= var". That is what tests are for;-)

Andy Jefferson added a comment - 22/Apr/11 03:20 PM
SVN trunk works on all SVN tests for JDOQL and JPQL

Guido Anzuoni added a comment - 22/Apr/11 04:02 PM
I confirm that it works in may env too :-)
Even if one of my queries (with subq) that contains a LIKE statement is badly transformed to SQL if query compilation cache
is enabled (yes, I know, test to demonstrate......I know, but maybe it rings some bells in the meantime).
Everything is fine if I turn off the cache.
The funny thing is the correct fragment is:
while if I turn cache on it becomes:
the parameter disappears.....