Issue Details (XML | Word | Printable)

Key: NUCRDBMS-430
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Yang ZHONG
Votes: 0
Watchers: 0
Operations

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

Mapping boolean field as integer-based can cause problem with JDOQL

Created: 12/Jul/10 07:49 AM   Updated: 20/Oct/10 09:30 AM   Resolved: 16/Jul/10 01:36 PM
Component/s: Queries
Affects Version/s: 2.1.1
Fix Version/s: 2.1.2, 2.2.0.m1

File Attachments: 1. Zip Archive NUCRDBMS-430.zip (3 kB)

Environment: Java 5, Linux

Datastore: IBM DB2
Severity: Production


 Description  « Hide
The new query generation uses default Java type mapping despite custome JDO metadata. That seems a serious regression from DataNucleus 2.0.5.

Schema generation and field access are still working fine. Query generation is the only thing wrong.

Sort Order: Ascending order - Click to sort in descending order
Yang ZHONG added a comment - 12/Jul/10 07:52 AM - edited
The attached Test Case shows both schema & field are fine, however query throws:

javax.jdo.JDODataStoreException: Exception thrown when executing query
at org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:319)
at org.datanucleus.jdo.JDOQuery.execute(JDOQuery.java:230)
at org.datanucleus.test.Main.main(Main.java:75)
NestedThrowablesStackTrace:
com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-401, SQLSTATE=42818, SQLERRMC==, DRIVER=3.59.81
at com.ibm.db2.jcc.am.dd.a(dd.java:676)
at com.ibm.db2.jcc.am.dd.a(dd.java:60)
at com.ibm.db2.jcc.am.dd.a(dd.java:127)
at com.ibm.db2.jcc.am.bn.c(bn.java:2546)
at com.ibm.db2.jcc.am.bn.d(bn.java:2534)
at com.ibm.db2.jcc.am.bn.a(bn.java:2026)
at com.ibm.db2.jcc.t4.cb.g(cb.java:140)
at com.ibm.db2.jcc.t4.cb.a(cb.java:40)
at com.ibm.db2.jcc.t4.q.a(q.java:32)
at com.ibm.db2.jcc.t4.rb.i(rb.java:135)
at com.ibm.db2.jcc.am.bn.gb(bn.java:1997)
at com.ibm.db2.jcc.am.cn.pc(cn.java:3009)
at com.ibm.db2.jcc.am.cn.b(cn.java:3786)
at com.ibm.db2.jcc.am.cn.bc(cn.java:678)
at com.ibm.db2.jcc.am.cn.executeQuery(cn.java:652)
at org.datanucleus.store.rdbms.SQLController.executeStatementQuery(SQLController.java:463)
at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecuteInternal(JDOQLQuery.java:757)
at org.datanucleus.store.query.Query$1.run(Query.java:1848)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:432)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:284)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.lang.Thread.run(Thread.java:810)

Andy Jefferson added a comment - 12/Jul/10 08:08 AM
Ample workarounds, including using JDOQL-Legacy, or setting the query filter to just "bool".
Note that no attempt has been made to show the generated SQL and hence debug the problem

Alexander Ley added a comment - 12/Jul/10 12:40 PM
For me it looks like this could be related to NUCRDBMS-427

Yang ZHONG added a comment - 12/Jul/10 07:02 PM
I had done a preliminary debuging. Since I'm totally new to the code, I hesitated to post any preliminary findings. However, if they can assist in any way, even if false later clarified by any one, here they are.

DataNucleus 2.1(.1) seems parsing "true == field" as EqualityExpression w/ LeftExpression(Literal) & RightExpression, and seems doing these in order:
    compile( LeftExpression);
    compile( RightExpression);

In particular, "compile( LeftExpression);" uses default Java type mapping for the Literal(Expression) i.e. "true" for the example.

That doesn't *seem* accurate. The compiler should (have) looked forward into RightExpression for MetaData in order to detertime at least
2-1. the literal value valid or not for the field. E.g. "true" will be invalud for non-boolean field
2-2. the custom Java type mapping to generate corresponding "compilation"

More example, we should (have) seen "1 == IntBoolField && 'Y' == CharBoolField" out of "true == IntBoolField && true == CharBoolField".

Although the examples are using boolean, we can clearly see the problem is much broader than just boolean. I'd recommend we update the summary to accurately reflect that.

Another problem, maybe worth another issue to be tracked separately, is the new compiler generates "'Y'" literally, that *seems* another serious regression from 2.0.x, as we all know "?"(Prepared Statement) is much faster.

Thanks!

Andy Jefferson added a comment - 12/Jul/10 07:22 PM
If you have other types that have problems then you provide a valid testcase that demonstrates them. You provide one for boolean, so that is what the issue is, since it uses its own expression type and handling there is specific to boolean.


The old compiler was flawed in that it put parameters in for some things and then swapped out the actual user parameters with their literal. Now behavious is well defined : is the user wants a parameter in their SQL they put a parameter in the JDOQL, so that is totally under the users control of they have parameters or not. Obviously if you think the old compiler was/is more suitable for your project then use 2.0, or use JDOQL-Legacy in 2.1.


You insist on talking of "serious regressions" yet all passes the TCKs before and now, and all of the available DN unit tests before and now (well actually it passes all tests WAY BETTER now). DN "supports" what it is tested for, and it is the responsibility of users to contribute tests for their situations that integrate directly with the existing test suite. Just saying "I have some case that worked before and doesn't now" achieves little. You still haven't quoted the SQL generated.

Yang ZHONG added a comment - 14/Jul/10 05:41 PM
Current generated SQL is
SELECT 'org.datanucleus.test.Bool' AS NUCLEUS_TYPE,A0.BOOL,A0.BOOL_ID FROM BOOL A0 WHERE 'Y' = A0.BOOL
which should have been
SELECT 'org.datanucleus.test.Bool' AS NUCLEUS_TYPE,A0.BOOL,A0.BOOL_ID FROM BOOL A0 WHERE 1 = A0.BOOL
even
SELECT 'org.datanucleus.test.Bool' AS NUCLEUS_TYPE,A0.BOOL,A0.BOOL_ID FROM BOOL A0 WHERE <1> = A0.BOOL

How to capture the generated SQL:
HTTP://WWW.DataNucleus.org/servlet/jira/browse/NUCRDBMS-432

Andy Jefferson added a comment - 16/Jul/10 01:36 PM
Works for me