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
Operations

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 JPQLSingleStringParser.java (24 kB)



 Description  « Hide
The problem is cause by the replace of the original subquery with DATANUCLEUS_.....in 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 JPQLSingleStringParser.java
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:
UPPER(`B1_SUB`.`DESCRIZIONE`) LIKE '%ASSOC%' ESCAPE '\\'
while if I turn cache on it becomes:
UPPER(`B1_SUB`.`DESCRIZIONE`) LIKE ESCAPE '\\'
the parameter disappears.....