| Bug #68411 | refresh() method sets TEXT fields to null | ||
|---|---|---|---|
| Submitted: | 17 Feb 2013 22:02 | Modified: | 10 Aug 2013 20:00 |
| Reporter: | Stew G | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Cluster: Cluster/J | Severity: | S1 (Critical) |
| Version: | 7.2.10 | OS: | Linux (Arch (3.7.6-1) x86_64) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | cluster, ClusterJ, clusterjpa | ||
[17 Feb 2013 22:05]
Stew G
Test class
Attachment: DBTest.java (text/x-java), 2.47 KiB.
[17 Feb 2013 22:08]
Stew G
MySQL cluster setup (ndb_mgm > show)
Attachment: ndb-show.txt (text/plain), 522 bytes.
[10 Jul 2013 20:00]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior with current development version: 54 test INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.2 165 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class "org.apache.openjpa.jdbc.sql.MySQLDictionary". 577 test INFO [main] openjpa.Enhance - Creating subclass for "[class DBTest]". This means that your application will be less efficient and will consume more memory than it would if you ran the OpenJPA enhancer. Additionally, lazy loading will not be available for one-to-one and many-to-one persistent attributes in types using field access; they will be loaded eagerly instead. FOUND: DBTest:[ 51, 1, 2, TEST_1, TEST_2 ] REFRESHED: DBTest:[ 51, 1, 2, TEST_1, TEST_2 ] Please try with current version 7.2.13 and inform us if bug is fixed for you.
[11 Aug 2013 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
Description: SETUP description: (1) MySQL Cluster, version 7.2.10. See configuration in the attachment. (2) OpenJPA version 2.2.1 (JAR: openjpa-all-2.2.1.jar) (3) ClusterJPA version 7.2.10 (JAR: clusterjpa-7.2.10.jar) ----------------------- PROBLEM description: Refreshing an entity from MySQL cluster through ClusterJPA results in a "null" value for its fields of type TEXT. How to repeat: [+] Using the attached test class (showing here only the few relevant lines): DBTest t = new DBTest("TEST_1","TEST_2", 1, 2); // Persisting an entity transaction.begin(); DBTest tManaged = em.merge(t); transaction.commit(); // Retrieving the same entity transaction.begin(); tManaged = em.find(DBTest.class, tManaged.getId()); transaction.commit(); System.out.println("FOUND: "+tManaged.toString()); // Refreshing the entity transaction.begin(); em.refresh(tManaged); transaction.commit(); System.out.println("REFRESHED: "+tManaged.toString()); ---------------------- [+] Using the table created as follows: CREATE TABLE Tests (id int(10) auto_increment primary key, text1 varchar(100), text2 text, i1 int(10), i2 int(10)) ENGINE ndbcluster; ---------------------- [+] Running the code results in this output: FOUND: DBTest:[ 201901, 1, 2, TEST_1, TEST_2 ] REFRESHED: DBTest:[ 201901, 1, 2, TEST_1, null ] ---------------------- [+] The expected output: FOUND: DBTest:[ 201901, 1, 2, TEST_1, TEST_2 ] REFRESHED: DBTest:[ 201901, 1, 2, TEST_1, TEST_2 ] ---------------------- [+] BRIEF EXPLANATION AND NOTES: * As you can see from the presented output, upon the retrieval of the entity the text2 field, of data type TEXT, was set correctly, but after the entity is refreshed it is null. * This is 100% reproducible. * The big problem is (also why I set the severity of this report to 'critical') that when working with JPA there is always stale data in the cache. There are sections of the code where you absolutely need to refresh the entities you are handling. * Sorry for the lengthy report, but I just wanted to be thorough!