Java Persistent Objects (JPOX)

[ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719#action_16719 ] 

Andy Jefferson commented on NUCRDBMS-193:
-----------------------------------------

Thx. Obviously the way to guarantee the situations that your app relies on is to provide testcases to our test suite. Await your patch(es), as well as what is "will fail" (stack trace etc)

> getObjectByID when primary key is java.util.UUID or Enum will fail
> ------------------------------------------------------------------
>
>                 Key: NUCRDBMS-193
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>    Affects Versions: 1.1.3
>         Environment: MySQL 5.1, Java 6.13
>            Reporter: Michael Brown
>
> The constructor of org.datanucleus.store.rdbms.sql.expression.StringLiteral requires that the parameter 'value' is either a String or a Character, and throws an exception if it is anything else (null accepted of course).
> In the RDBMS plugins.xml, there seems to be an assumption that any java type that is persisted as a string, can use StringLiteral as the literal-class. Examples are CurrencyMapping, LocaleMapping, StringBufferMapping, TimeZoneMapping, URLMapping, URIMapping and UUIDMapping.
> It is this confusion that breaks getObjectByID, and perhaps other areas (haven't experienced them yet).
> The fix I provide modifies StringLiteral to fit in with this general assumption, that it can accept java types that are backed by a string in the database, by using the associated ObjectStringConverter for the provided JavaTypeMapping.
> Whilst investigating this issue I also noticed an issue with EnumMapping. There exists an EnumLiteral to handle both the String and Integer mapped cases, but in plugins.xml EnumLiteral utilizes a StringLiteral. So I have modified that.
> Additionally, EnumLiteral makes an assumption both that StringLiteral and IntegerLiteral can take an Enum value, which I believe to be false in both cases. Even with the above fix for StringLiteral, an Enum correctly does not have an ObjectStringConverter associated, as it can be either string or integer...   I include a fix for this as well.
> All fixes should be in the attached patch, that I will upload shortly. They are quite short, so easy to check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Brown updated NUCRDBMS-193:
-----------------------------------

    Attachment: patches.zip

Patches to fix above problems

> getObjectByID when primary key is java.util.UUID or Enum will fail
> ------------------------------------------------------------------
>
>                 Key: NUCRDBMS-193
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>    Affects Versions: 1.1.3
>         Environment: MySQL 5.1, Java 6.13
>            Reporter: Michael Brown
>         Attachments: patches.zip
>
>
> The constructor of org.datanucleus.store.rdbms.sql.expression.StringLiteral requires that the parameter 'value' is either a String or a Character, and throws an exception if it is anything else (null accepted of course).
> In the RDBMS plugins.xml, there seems to be an assumption that any java type that is persisted as a string, can use StringLiteral as the literal-class. Examples are CurrencyMapping, LocaleMapping, StringBufferMapping, TimeZoneMapping, URLMapping, URIMapping and UUIDMapping.
> It is this confusion that breaks getObjectByID, and perhaps other areas (haven't experienced them yet).
> The fix I provide modifies StringLiteral to fit in with this general assumption, that it can accept java types that are backed by a string in the database, by using the associated ObjectStringConverter for the provided JavaTypeMapping.
> Whilst investigating this issue I also noticed an issue with EnumMapping. There exists an EnumLiteral to handle both the String and Integer mapped cases, but in plugins.xml EnumLiteral utilizes a StringLiteral. So I have modified that.
> Additionally, EnumLiteral makes an assumption both that StringLiteral and IntegerLiteral can take an Enum value, which I believe to be false in both cases. Even with the above fix for StringLiteral, an Enum correctly does not have an ObjectStringConverter associated, as it can be either string or integer...   I include a fix for this as well.
> All fixes should be in the attached patch, that I will upload shortly. They are quite short, so easy to check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721#action_16721 ] 

Michael Brown commented on NUCRDBMS-193:
----------------------------------------

Hi Andy.

I agree that a test case is the best way, but I am unfortunately on a tight time budget at the moment.
However, a stack trace is of course the least I could have done...

I have removed the patches from our local copy of DataNucleus, and re-run our product regression tests. The following stack trace results when attempting to call 'getObjectByID' with a 'java.util.UUID' key field. The test passes when the patches are applied.

I include the whole stack trace for completeness. However any lines with 'com.assethouse.persistence' can be ignored as they represent a facade on top of JDO.

Thank you for taking the time to look at this,
Michael.



javax.persistence.PersistenceException: Cannot create org.datanucleus.store.rdbms.sql.expression.StringLiteral for value of type java.util.UUID
        at com.assethouse.persistence.jdobridge.JDOEntityManager.rethrow(JDOEntityManager.java:116)
        at com.assethouse.persistence.jdobridge.JDOEntityManager.getReference(JDOEntityManager.java:329)
        at com.assethouse.persistence.jdobridge.JDOEntityManager.find(JDOEntityManager.java:261)
        at com.assethouse.goya.common.BugTest.testDuplicateInOrderedSet(BugTest.java:152)
Caused by: javax.jdo.JDOException: Cannot create org.datanucleus.store.rdbms.sql.expression.StringLiteral for value of type java.util.UUID
NestedThrowables:
org.datanucleus.exceptions.NucleusException: Cannot create org.datanucleus.store.rdbms.sql.expression.StringLiteral for value of type java.util.UUID
        at org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:408)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1676)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1767)
        at com.assethouse.persistence.jdobridge.JDOEntityManager.getReference(JDOEntityManager.java:315)
Caused by: org.datanucleus.exceptions.NucleusException: Cannot create org.datanucleus.store.rdbms.sql.expression.StringLiteral for value of type java.util.UUID
        at org.datanucleus.store.rdbms.sql.expression.StringLiteral.<init>(StringLiteral.java:59)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at org.datanucleus.util.ClassUtils.newInstance(ClassUtils.java:94)
        at org.datanucleus.store.rdbms.sql.expression.SQLExpressionFactory.newLiteral(SQLExpressionFactory.java:203)
        at org.datanucleus.store.rdbms.sql.expression.ObjectLiteral.getEqualityExpressionForObjectExpression(ObjectLiteral.java:212)
        at org.datanucleus.store.rdbms.sql.expression.ObjectLiteral.eq(ObjectLiteral.java:88)
        at org.datanucleus.store.rdbms.sql.expression.ObjectExpression.eq(ObjectExpression.java:221)
        at org.datanucleus.store.rdbms.RDBMSStoreHelper.getClassNameForIdKeyUsingDiscriminator(RDBMSStoreHelper.java:341)
        at org.datanucleus.store.rdbms.RDBMSManager.getClassNameForObjectID(RDBMSManager.java:1242)
        at org.datanucleus.ObjectManagerImpl.findObject(ObjectManagerImpl.java:2394)
        at org.datanucleus.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1671)



> getObjectByID when primary key is java.util.UUID or Enum will fail
> ------------------------------------------------------------------
>
>                 Key: NUCRDBMS-193
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>    Affects Versions: 1.1.3
>         Environment: MySQL 5.1, Java 6.13
>            Reporter: Michael Brown
>         Attachments: patches.zip
>
>
> The constructor of org.datanucleus.store.rdbms.sql.expression.StringLiteral requires that the parameter 'value' is either a String or a Character, and throws an exception if it is anything else (null accepted of course).
> In the RDBMS plugins.xml, there seems to be an assumption that any java type that is persisted as a string, can use StringLiteral as the literal-class. Examples are CurrencyMapping, LocaleMapping, StringBufferMapping, TimeZoneMapping, URLMapping, URIMapping and UUIDMapping.
> It is this confusion that breaks getObjectByID, and perhaps other areas (haven't experienced them yet).
> The fix I provide modifies StringLiteral to fit in with this general assumption, that it can accept java types that are backed by a string in the database, by using the associated ObjectStringConverter for the provided JavaTypeMapping.
> Whilst investigating this issue I also noticed an issue with EnumMapping. There exists an EnumLiteral to handle both the String and Integer mapped cases, but in plugins.xml EnumLiteral utilizes a StringLiteral. So I have modified that.
> Additionally, EnumLiteral makes an assumption both that StringLiteral and IntegerLiteral can take an Enum value, which I believe to be false in both cases. Even with the above fix for StringLiteral, an Enum correctly does not have an ObjectStringConverter associated, as it can be either string or integer...   I include a fix for this as well.
> All fixes should be in the attached patch, that I will upload shortly. They are quite short, so easy to check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Jefferson resolved NUCRDBMS-193.
-------------------------------------

    Fix Version/s: 1.1.4
       Resolution: Fixed

Changes are in SVN trunk. The attached aren't in patch format (they are diff, but that isn't patch) so had to be approximated. Left as an exercise for whether they are applied correctly since no tests possible

> getObjectByID when primary key is java.util.UUID or Enum will fail
> ------------------------------------------------------------------
>
>                 Key: NUCRDBMS-193
>                 URL: http://www.datanucleus.org/servlet/jira/browse/NUCRDBMS-193
>             Project: DataNucleus RDBMS
>          Issue Type: Bug
>    Affects Versions: 1.1.3
>         Environment: MySQL 5.1, Java 6.13
>            Reporter: Michael Brown
>             Fix For: 1.1.4
>
>         Attachments: patches.zip
>
>
> The constructor of org.datanucleus.store.rdbms.sql.expression.StringLiteral requires that the parameter 'value' is either a String or a Character, and throws an exception if it is anything else (null accepted of course).
> In the RDBMS plugins.xml, there seems to be an assumption that any java type that is persisted as a string, can use StringLiteral as the literal-class. Examples are CurrencyMapping, LocaleMapping, StringBufferMapping, TimeZoneMapping, URLMapping, URIMapping and UUIDMapping.
> It is this confusion that breaks getObjectByID, and perhaps other areas (haven't experienced them yet).
> The fix I provide modifies StringLiteral to fit in with this general assumption, that it can accept java types that are backed by a string in the database, by using the associated ObjectStringConverter for the provided JavaTypeMapping.
> Whilst investigating this issue I also noticed an issue with EnumMapping. There exists an EnumLiteral to handle both the String and Integer mapped cases, but in plugins.xml EnumLiteral utilizes a StringLiteral. So I have modified that.
> Additionally, EnumLiteral makes an assumption both that StringLiteral and IntegerLiteral can take an Enum value, which I believe to be false in both cases. Even with the above fix for StringLiteral, an Enum correctly does not have an ObjectStringConverter associated, as it can be either string or integer...   I include a fix for this as well.
> All fixes should be in the attached patch, that I will upload shortly. They are quite short, so easy to check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.datanucleus.org/servlet/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira