OpenJPA
  1. OpenJPA
  2. OPENJPA-525

Inserts new entity with NULL value for Clob column actually inserts empty string

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0, 1.0.2, 1.1.0, 1.2.1, 2.0.0
    • Fix Version/s: 1.1.1, 1.3.0, 2.0.0-M3
    • Component/s: None
    • Labels:
      None
    • Environment:
      OpenJPA 1.0.0, 1.0.2
      Oracle XE 10g (JDBC driver 10.2.0.3.0
      JRE 1.5.0_13
    • Patch Info:
      Patch Available

      Description

      Inserts new entity with NULL value for Clob column with "nullable = true" actually inserts empty string as the value!

      Here's the persistence class:
      public class Exam...

      { @Lob private String text; }
      1. OPENJPA-525-3-branch1.1.x.patch
        4 kB
        Amy Yang
      2. OPENJPA525.patch
        3 kB
        Amy Yang
      3. OPENJPA-525.3.patch
        2 kB
        Milosz Tylenda
      4. OPENJPA-525.2.patch
        3 kB
        Albert Lee
      5. OPENJPA525_1_1_x.patch
        3 kB
        Amy Yang

        Issue Links

          Activity

          Hide
          Milosz Tylenda added a comment -

          Reopen if needs porting to other branches.

          Show
          Milosz Tylenda added a comment - Reopen if needs porting to other branches.
          Hide
          Milosz Tylenda added a comment -

          I have ported OPENJPA-525.3.patch along with new tests in TestSerializedLobs to branch 1.3.x.

          Mike, you can consider applying the fix to other branches or close this bug.

          Show
          Milosz Tylenda added a comment - I have ported OPENJPA-525 .3.patch along with new tests in TestSerializedLobs to branch 1.3.x. Mike, you can consider applying the fix to other branches or close this bug.
          Hide
          David Ezzio added a comment -

          Milosz and Amy, thank you!

          Applied Milosz's OPENJPA-525.3.patch to trunk at 807642.

          Show
          David Ezzio added a comment - Milosz and Amy, thank you! Applied Milosz's OPENJPA-525 .3.patch to trunk at 807642.
          Hide
          Amy Yang added a comment -

          Oracle: Database 10g Enterprise Edition Release 11g
          Driver: Oracle JDBC Driver version - "11.1.0.7.0-Production"

          MySQL: 5.1.37-community MySQL Community Server (GPL)

          branch1.1.x: r807362
          TestSerializedLobs passed on oracle and mysql.
          TestInputStreamLob passed on mysql. on Oracle, it's result is "Tests run: 13, Failures: 1, Errors: 12, Skipped: 0". The failure isn't caused by the patch. It failed before r786218 too. I think it should be tracked by OPENJPA-1248.
          TestReaderLob: on oracle, the result is similar with TestInputStreamLob. The failure isn't caused by the patch either. We should track it with OPENJPA-1248 too. I'll paste a stack trace to that issue.
          on mysql, even before r786218, testUpdateWithNull will fail. at r807362 it also failed. I.e. the OPENJPA-525-3-branch1.1.x.patch doesn't cause any regression. I'll create a new JIRA issue to track the failure.

          trunk: r807465+OPENJPA-525.3.patch
          TestSerializedLobs: same as 1.1.x branch
          TestInputStreamLob: same as 1.1.x branch.
          TestReaderLob: same as 1.1.x branch

          So I think OPENJPA-525.3.patch does resolve the original problem of this issue and safe to be checked in.

          Thanks,
          Amy

          Show
          Amy Yang added a comment - Oracle: Database 10g Enterprise Edition Release 11g Driver: Oracle JDBC Driver version - "11.1.0.7.0-Production" MySQL: 5.1.37-community MySQL Community Server (GPL) branch1.1.x: r807362 TestSerializedLobs passed on oracle and mysql. TestInputStreamLob passed on mysql. on Oracle, it's result is "Tests run: 13, Failures: 1, Errors: 12, Skipped: 0". The failure isn't caused by the patch. It failed before r786218 too. I think it should be tracked by OPENJPA-1248 . TestReaderLob: on oracle, the result is similar with TestInputStreamLob. The failure isn't caused by the patch either. We should track it with OPENJPA-1248 too. I'll paste a stack trace to that issue. on mysql, even before r786218, testUpdateWithNull will fail. at r807362 it also failed. I.e. the OPENJPA-525 -3-branch1.1.x.patch doesn't cause any regression. I'll create a new JIRA issue to track the failure. trunk: r807465+ OPENJPA-525 .3.patch TestSerializedLobs: same as 1.1.x branch TestInputStreamLob: same as 1.1.x branch. TestReaderLob: same as 1.1.x branch So I think OPENJPA-525 .3.patch does resolve the original problem of this issue and safe to be checked in. Thanks, Amy
          Hide
          David Ezzio added a comment -

          Applied Amy's patch OPENJPA-525-3-branch1.1.x.patch to branch 1.1.1 at revision 807362. Includes merge from Milosz's change on trunk at 790666 that renamed misnamed test cases.

          Amy, can you let us know the results of testing this change with MySQL and Oracle (identifying DB and driver versions), as well as let us know the results of testing Milosz's patch on trunk with the same setups?

          Show
          David Ezzio added a comment - Applied Amy's patch OPENJPA-525 -3-branch1.1.x.patch to branch 1.1.1 at revision 807362. Includes merge from Milosz's change on trunk at 790666 that renamed misnamed test cases. Amy, can you let us know the results of testing this change with MySQL and Oracle (identifying DB and driver versions), as well as let us know the results of testing Milosz's patch on trunk with the same setups?
          Hide
          Amy Yang added a comment -

          patch for 1.1.x based on Milosz's patch

          Show
          Amy Yang added a comment - patch for 1.1.x based on Milosz's patch
          Hide
          Amy Yang added a comment -

          hi Milosz & Albert,
          thank you very much for looking into this issue.
          Milosz , I've tried OPENJPA-525.3.patch on oracle. TestSerializedLobs can pass with it.
          I also run TestInputStreamLob on mysql with it and the case can pass too. Could you please check in the patch?

          Thanks,
          Amy

          Show
          Amy Yang added a comment - hi Milosz & Albert, thank you very much for looking into this issue. Milosz , I've tried OPENJPA-525 .3.patch on oracle. TestSerializedLobs can pass with it. I also run TestInputStreamLob on mysql with it and the case can pass too. Could you please check in the patch? Thanks, Amy
          Hide
          Milosz Tylenda added a comment -

          Albert, could you apply the attached OPENJPA-525.3.patch to trunk and see whether it works for you? With that patch TestSerializedLobs.testNullableClob passes with Oracle.

          I have moved the call to translate method from AbstractResult.getObject to ResultSetResult.getObjectInternal. Now ResultSetResult.getObjectInternal receives a Column instead of a bare Number and can determine if the Coulmn is of type CLOB.

          Show
          Milosz Tylenda added a comment - Albert, could you apply the attached OPENJPA-525 .3.patch to trunk and see whether it works for you? With that patch TestSerializedLobs.testNullableClob passes with Oracle. I have moved the call to translate method from AbstractResult.getObject to ResultSetResult.getObjectInternal. Now ResultSetResult.getObjectInternal receives a Column instead of a bare Number and can determine if the Coulmn is of type CLOB.
          Hide
          Milosz Tylenda added a comment -

          To clarify: OpenJPA persists an empty CLOB (Oracle-specific) when value to be persisted is null. Neither of the patches changes that. What the patches try to do is when the empty CLOB is read back, it is detected that the CLOB is empty and a null is returned. Without the patches, getString is called on the empty CLOB which gives an empty string to the user.

          Amy's patch fixes the issue (TestSerializedLobs.testNullableClob passes with Oracle) but causes Albert's failure.
          Albert's patch breaks the Oracle behaviour again (TestSerializedLobs.testNullableClob fails with Oracle) but fixes the error introduced by Amy's patch (so it is basically the state when no patch has been applied in terms of functionality).

          Show
          Milosz Tylenda added a comment - To clarify: OpenJPA persists an empty CLOB (Oracle-specific) when value to be persisted is null. Neither of the patches changes that. What the patches try to do is when the empty CLOB is read back, it is detected that the CLOB is empty and a null is returned. Without the patches, getString is called on the empty CLOB which gives an empty string to the user. Amy's patch fixes the issue (TestSerializedLobs.testNullableClob passes with Oracle) but causes Albert's failure. Albert's patch breaks the Oracle behaviour again (TestSerializedLobs.testNullableClob fails with Oracle) but fixes the error introduced by Amy's patch (so it is basically the state when no patch has been applied in terms of functionality).
          Hide
          Milosz Tylenda added a comment -

          This issue is Oracle-specific.

          To answer Amy's initial question (unfortunately that comment is visible only when you are logged in):

          > We're using empty_lob() instead of "null" when the Lob field has no value even it is nullable. is there any historical reason to do so?

          I think the reason is: if we set a LOB column to null we are not able to later update that column with a string longer that 4000 chars. Most probably it was needed in Oracle 8 times but looks like is not needed anymore (starting from Oracle 9 or 10). We should consider reworking our Oracle LOB support - there are chances that some Oracle-specific code can now be avoided and issues like this will disappear.

          I will open a new issue for the idea of reworking Oracle LOB support.

          Show
          Milosz Tylenda added a comment - This issue is Oracle-specific. To answer Amy's initial question (unfortunately that comment is visible only when you are logged in): > We're using empty_lob() instead of "null" when the Lob field has no value even it is nullable. is there any historical reason to do so? I think the reason is: if we set a LOB column to null we are not able to later update that column with a string longer that 4000 chars. Most probably it was needed in Oracle 8 times but looks like is not needed anymore (starting from Oracle 9 or 10). We should consider reworking our Oracle LOB support - there are chances that some Oracle-specific code can now be avoided and issues like this will disappear. I will open a new issue for the idea of reworking Oracle LOB support.
          Hide
          Milosz Tylenda added a comment -

          Although Amy's patch caused more failures in streaming LOB functionality, that functionality does not work without the patch either. I have double checked this and even 1.2.0 and 1.1.0 releases do not pass all the tests. I will open a new issue for possible fix of streaming LOB.

          Show
          Milosz Tylenda added a comment - Although Amy's patch caused more failures in streaming LOB functionality, that functionality does not work without the patch either. I have double checked this and even 1.2.0 and 1.1.0 releases do not pass all the tests. I will open a new issue for possible fix of streaming LOB.
          Hide
          Milosz Tylenda added a comment -

          I started looking into this problem but no success so far. I will again be out of source for the first half of August, so if someone needs it earlier, grab it.

          Show
          Milosz Tylenda added a comment - I started looking into this problem but no success so far. I will again be out of source for the first half of August, so if someone needs it earlier, grab it.
          Hide
          Milosz Tylenda added a comment -

          Albert,

          You don't run into problems with Derby and DB2 because LOB streaming requires other databases (see AbstractLOBTest), otherwise it is basically a no-op.

          Yes, the failing tests passed before the original patch although they were not executed by the default test suite because of incorrect names.

          For me, you can go ahead with the commit. I have little time this week and then I start vacation. I will dig into this problem but probably no earlier than Jul 20.

          Show
          Milosz Tylenda added a comment - Albert, You don't run into problems with Derby and DB2 because LOB streaming requires other databases (see AbstractLOBTest), otherwise it is basically a no-op. Yes, the failing tests passed before the original patch although they were not executed by the default test suite because of incorrect names. For me, you can go ahead with the commit. I have little time this week and then I start vacation. I will dig into this problem but probably no earlier than Jul 20.
          Hide
          Albert Lee added a comment -

          Milosz,

          Did you make any progress on testing the MySQL db with the fixes? Are the failing tests passed before the original patch?

          Do you have any objection if we commit the changes so that it reverts the original regression first. Then figure out what are the problems that you have encountered since the original fix had the observed regression?

          If I don't hear from you (or anyone) soon, I shall go ahead with the commit.

          Thanks,
          Albert Lee.

          Show
          Albert Lee added a comment - Milosz, Did you make any progress on testing the MySQL db with the fixes? Are the failing tests passed before the original patch? Do you have any objection if we commit the changes so that it reverts the original regression first. Then figure out what are the problems that you have encountered since the original fix had the observed regression? If I don't hear from you (or anyone) soon, I shall go ahead with the commit. Thanks, Albert Lee.
          Hide
          Albert Lee added a comment -

          Milosz,

          Thanks for trying the patch on MySQL.

          I did not run into any problem in Derby and DB2. Probably it is some db specific feature.

          How is the failure surfaced in the test? What is the symptoms looks like? Do you have any exception stack to look at ? Do you have any idea what may have gone wrong? Not sure how is the patch affect Oracle db?

          Albert Lee.

          Show
          Albert Lee added a comment - Milosz, Thanks for trying the patch on MySQL. I did not run into any problem in Derby and DB2. Probably it is some db specific feature. How is the failure surfaced in the test? What is the symptoms looks like? Do you have any exception stack to look at ? Do you have any idea what may have gone wrong? Not sure how is the patch affect Oracle db? Albert Lee.
          Hide
          Milosz Tylenda added a comment -

          Hi Albert. I have tried the patch with MySQL and it resolved most of the LOB streaming errors. Unfortunately one LOB streaming test still fails and it looks like another one started failing:

          testQueryQualifiedId(org.apache.openjpa.persistence.jdbc.maps.spec_10_1_27_ex6.TestSpec10_1_27_Ex6)
          testUpdateWithNull(org.apache.openjpa.jdbc.meta.strats.TestReaderLob)

          Show
          Milosz Tylenda added a comment - Hi Albert. I have tried the patch with MySQL and it resolved most of the LOB streaming errors. Unfortunately one LOB streaming test still fails and it looks like another one started failing: testQueryQualifiedId(org.apache.openjpa.persistence.jdbc.maps.spec_10_1_27_ex6.TestSpec10_1_27_Ex6) testUpdateWithNull(org.apache.openjpa.jdbc.meta.strats.TestReaderLob)
          Hide
          Albert Lee added a comment -

          Attempt to fix the incompatible ClassCastException:

          1) reverted the translate() method implementation
          2) enhanced the AbstractResult.getStringInternal() to include a new parameter indicating if the String is a ClobString, such that the ResultSetResult.getStringInternal() can use it to determine if the _dict.getClobString() or _dict.getString() should be call.

          After this patch is applied, OpenJPA trunk built and all tests ran successfully.

          Amy and Milosz, can you please try this patch to verify it does solve the original and subsequent regression problems?

          Thanks,
          Albert Lee.

          Show
          Albert Lee added a comment - Attempt to fix the incompatible ClassCastException: 1) reverted the translate() method implementation 2) enhanced the AbstractResult.getStringInternal() to include a new parameter indicating if the String is a ClobString, such that the ResultSetResult.getStringInternal() can use it to determine if the _dict.getClobString() or _dict.getString() should be call. After this patch is applied, OpenJPA trunk built and all tests ran successfully. Amy and Milosz, can you please try this patch to verify it does solve the original and subsequent regression problems? Thanks, Albert Lee.
          Hide
          Albert Lee added a comment -

          After the latest patch, I am seeing the following exception:

          Caused by: java.lang.ClassCastException: org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn incompatible with java.lang.Number
          at org.apache.openjpa.jdbc.sql.ResultSetResult.getCharacterStreamInternal(ResultSetResult.java:305)
          at org.apache.openjpa.jdbc.sql.ResultSetResult.getObjectInternal(ResultSetResult.java:423)
          at org.apache.openjpa.jdbc.sql.AbstractResult.getObject(AbstractResult.java:694)
          at org.apache.openjpa.jdbc.meta.strats.HandlerStrategies.loadDataStore(HandlerStrategies.java:220)
          at org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.load(HandlerFieldStrategy.java:186)
          at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:912)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1015)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:391)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:290)
          at com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:147)
          at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
          at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
          at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1003)
          at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:961)

          Look further in the changes and found in:

          ResultSetResult.java

          protected Object translate(Object obj, Joins joins)
          throws SQLException

          { if (obj instanceof Number) return obj; // getStringInternal will take care the translation if (obj instanceof Column && ((Column) obj).getType() == Types.CLOB) return obj; return Numbers.valueOf(findObject(obj, joins)); }

          The newly added code will always return object which is a Column type. However this method is expect a Number object to be returned.

          // getStringInternal will take care the translation
          if (obj instanceof Column && ((Column) obj).getType() == Types.CLOB)
          return obj;

          Albert Lee.

          Show
          Albert Lee added a comment - After the latest patch, I am seeing the following exception: Caused by: java.lang.ClassCastException: org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn incompatible with java.lang.Number at org.apache.openjpa.jdbc.sql.ResultSetResult.getCharacterStreamInternal(ResultSetResult.java:305) at org.apache.openjpa.jdbc.sql.ResultSetResult.getObjectInternal(ResultSetResult.java:423) at org.apache.openjpa.jdbc.sql.AbstractResult.getObject(AbstractResult.java:694) at org.apache.openjpa.jdbc.meta.strats.HandlerStrategies.loadDataStore(HandlerStrategies.java:220) at org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy.load(HandlerFieldStrategy.java:186) at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:912) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1015) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:391) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:290) at com.ibm.ws.persistence.jdbc.kernel.WsJpaJDBCStoreManager.initialize(WsJpaJDBCStoreManager.java:147) at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111) at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57) at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1003) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:961) Look further in the changes and found in: ResultSetResult.java protected Object translate(Object obj, Joins joins) throws SQLException { if (obj instanceof Number) return obj; // getStringInternal will take care the translation if (obj instanceof Column && ((Column) obj).getType() == Types.CLOB) return obj; return Numbers.valueOf(findObject(obj, joins)); } The newly added code will always return object which is a Column type. However this method is expect a Number object to be returned. // getStringInternal will take care the translation if (obj instanceof Column && ((Column) obj).getType() == Types.CLOB) return obj; Albert Lee.
          Hide
          Milosz Tylenda added a comment -

          Could you please check the possible impact this change has on the streaming LOB functionality? Not very sure it is because of this this but that functionality is now broken. The tests are named ReaderLobTest and InputStreamLobTest. Although they are not executed by the test suite, the functionality is described in user manual (I have no idea why someone named the tests that way causing the test suite to skip them - oversight?). Note that the tests require a database other than Derby to run on.

          One of stack traces I am receiving with MySQL:

          at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:984)
          at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:878)
          at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:201)
          at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:464)
          at org.apache.openjpa.jdbc.meta.strats.AbstractLobTest.testSetResetAndFlush(AbstractLobTest.java:254)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at junit.framework.TestCase.runTest(TestCase.java:154)
          at junit.framework.TestCase.runBare(TestCase.java:127)
          at org.apache.openjpa.persistence.test.PersistenceTestCase.runBare(PersistenceTestCase.java:475)
          at junit.framework.TestResult$1.protect(TestResult.java:106)
          at junit.framework.TestResult.runProtected(TestResult.java:124)
          at junit.framework.TestResult.run(TestResult.java:109)
          at junit.framework.TestCase.run(TestCase.java:118)
          at org.apache.openjpa.persistence.test.PersistenceTestCase.run(PersistenceTestCase.java:190)
          at junit.framework.TestSuite.runTest(TestSuite.java:208)
          at junit.framework.TestSuite.run(TestSuite.java:203)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
          at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
          at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
          at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
          Caused by: java.lang.ClassCastException: org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn
          at org.apache.openjpa.jdbc.sql.ResultSetResult.getCharacterStreamInternal(ResultSetResult.java:305)
          at org.apache.openjpa.jdbc.sql.AbstractResult.getCharacterStream(AbstractResult.java:499)
          at org.apache.openjpa.jdbc.meta.strats.LobFieldStrategy.load(LobFieldStrategy.java:181)
          at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:912)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1015)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967)
          at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:628)
          at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
          at org.apache.openjpa.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:393)
          at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116)
          at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78)
          at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2989)
          at org.apache.openjpa.kernel.StateManagerImpl.load(StateManagerImpl.java:405)
          at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:971)
          ... 32 more

          Show
          Milosz Tylenda added a comment - Could you please check the possible impact this change has on the streaming LOB functionality? Not very sure it is because of this this but that functionality is now broken. The tests are named ReaderLobTest and InputStreamLobTest. Although they are not executed by the test suite, the functionality is described in user manual (I have no idea why someone named the tests that way causing the test suite to skip them - oversight?). Note that the tests require a database other than Derby to run on. One of stack traces I am receiving with MySQL: at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:984) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:878) at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:201) at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:464) at org.apache.openjpa.jdbc.meta.strats.AbstractLobTest.testSetResetAndFlush(AbstractLobTest.java:254) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.openjpa.persistence.test.PersistenceTestCase.runBare(PersistenceTestCase.java:475) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.apache.openjpa.persistence.test.PersistenceTestCase.run(PersistenceTestCase.java:190) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.ClassCastException: org.apache.openjpa.jdbc.schema.DynamicSchemaFactory$DynamicColumn at org.apache.openjpa.jdbc.sql.ResultSetResult.getCharacterStreamInternal(ResultSetResult.java:305) at org.apache.openjpa.jdbc.sql.AbstractResult.getCharacterStream(AbstractResult.java:499) at org.apache.openjpa.jdbc.meta.strats.LobFieldStrategy.load(LobFieldStrategy.java:181) at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:912) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1015) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:628) at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116) at org.apache.openjpa.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:393) at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116) at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78) at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2989) at org.apache.openjpa.kernel.StateManagerImpl.load(StateManagerImpl.java:405) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:971) ... 32 more
          Hide
          David Ezzio added a comment -

          This bug appears to affect all branches made prior to rev 787868, and branch owners may want to merge the change. This bug should be closed after allowing a reasonable period of time for branch owners to take action.

          Show
          David Ezzio added a comment - This bug appears to affect all branches made prior to rev 787868, and branch owners may want to merge the change. This bug should be closed after allowing a reasonable period of time for branch owners to take action.
          Hide
          David Ezzio added a comment -

          Merged change 786218 (Amy's patch) to trunk at change 787868

          Show
          David Ezzio added a comment - Merged change 786218 (Amy's patch) to trunk at change 787868
          Hide
          David Ezzio added a comment -

          Applied Amy's 1.1.x patch to the 1.1.x branch at rev 786218

          Show
          David Ezzio added a comment - Applied Amy's 1.1.x patch to the 1.1.x branch at rev 786218
          Hide
          Amy Yang added a comment -

          this is for branch1.1.x

          Show
          Amy Yang added a comment - this is for branch1.1.x
          Hide
          Amy Yang added a comment -

          The patch is created in trunk.

          The bug in ResultSetResult prevents invocation to getClobString() on the dictionary class.

          Show
          Amy Yang added a comment - The patch is created in trunk. The bug in ResultSetResult prevents invocation to getClobString() on the dictionary class.

            People

            • Assignee:
              Milosz Tylenda
              Reporter:
              Frank Le
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development