Issue Details (XML | Word | Printable)

Key: NUCRDBMS-250
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Michael Brown
Votes: 0
Watchers: 1
Operations

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

getObjectById on persistent class that has a java.util.Date identity and a discriminator causes invalid SQL exception

Created: 25/Aug/09 03:54 PM   Updated: 11/Sep/09 08:41 AM   Resolved: 03/Sep/09 01:25 PM
Component/s: None
Affects Version/s: 2.0.0.m1
Fix Version/s: 2.0.0.m2

File Attachments: 1. Text File discrim_test.patch (14 kB)
2. Zip Archive src.zip (2 kB)

Environment: Ubuntu 9.04. NetBeans 6.7.1. Java 1.6.0_13. hsql

Datastore: HSQL
Severity: Development


 Description  « Hide
getObjectById on persistent class that has a java.util.Date identity and a discriminator causes invalid SQL exception.

A simple class with two date fields and a discriminator column has an instance populated and persisted.

In another transaction, use getObjectById(Class, Object) to retrieve the instance. Result is as follows:

javax.jdo.JDODataStoreException: java.sql.SQLException: Wrong data type: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff] in statement [SELECT A0.DISCRIMINATOR FROM A A0 WHERE 'Tue Aug 25 14:34:43 BST 2009' = A0."KEY"]
        at org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:324)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1657)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1748)
        at org.datanucleus.test.Main.main(Main.java:55)
NestedThrowablesStackTrace:
java.sql.SQLException: Wrong data type: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff] in statement [SELECT A0.DISCRIMINATOR FROM A A0 WHERE 'Tue Aug 25 14:34:43 BST 2009' = A0."KEY"]
org.datanucleus.exceptions.NucleusDataStoreException: java.sql.SQLException: Wrong data type: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff] in statement [SELECT A0.DISCRIMINATOR FROM A A0 WHERE 'Tue Aug 25 14:34:43 BST 2009' = A0."KEY"]
        at org.datanucleus.store.rdbms.RDBMSStoreHelper.getClassNameForIdKeyUsingDiscriminator(RDBMSStoreHelper.java:391)
        at org.datanucleus.store.rdbms.RDBMSStoreManager.getClassNameForObjectID(RDBMSStoreManager.java:1228)
        at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2382)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1652)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1748)
        at org.datanucleus.test.Main.main(Main.java:55)

Although I have tried to investigate this problem, I have come up a blank so far.
I can however say that it does not happen if there is no discriminator.


Sort Order: Ascending order - Click to sort in descending order
Michael Brown added a comment - 25/Aug/09 04:01 PM
Test case based on template in SVN.
The exception shown earlier is thrown from the call to getObjectById in the second transaction.

Andy Jefferson added a comment - 25/Aug/09 04:45 PM
Why not just look at org.datanucleus.store.rdbms.sql.expression.TemporalLiteral at the end. The thing labelled TODO.

Michael Brown added a comment - 25/Aug/09 06:49 PM
I wonder why this doesn't effect queries or instances without a discriminator. I suppose there must be many ways of constructing the same filter. Perhaps one day I'll understand the innards of DN enough to know the answers.

Thanks for the suggestion, I'll take a closer look in the morning. A second attempt is definitely called for.

Michael Brown added a comment - 01/Sep/09 02:20 PM
After updating I noticed that you had already made one change to the code area in question.
I've updated it to account for a few other cases, and added some new cases to DateTest.
The test I have added tests both key field of java.util.Date with default persistence, and java.util.Date with varchar persistence.

There is still a problem that I am struggling with, and so the patch here isn't final. I'd appreciate it if you could take a look.

The test DateTest.testDiscriminatorB, which uses Date as VARCHAR shows the effect. In the first try block, it persists a DateHolderB, and the logs I have (temporarily) added to CharRDBMSMapping and TemporalLiteral show that it is correctly converting to string through the CharRDBMSMapping. The second try block attempts to find the instance, and those same logs show that the field 'key' is now mapped as TimestampRDBMSMapping.

This is where I am stumped, why does it have a different mapping to the earlier transaction? Is it perhaps something to do with the fact that it is searching for a discriminator, and so perhaps has not yet properly loaded metadata?.. It's a rough guess so far. Please advise.

Andy Jefferson added a comment - 03/Sep/09 10:03 AM
Code committed to SVN as well as fix to ObjectLiteral, tests pass. Removed DEBUG. Left to raiser to define if this is complete

Michael Brown added a comment - 03/Sep/09 12:39 PM
Thanks Andy. I've checked using DN tests from SVN and our own product tests. This certainly looks fixed.