Known issues - Floats and doubles may lose precision when stored.
Hi, I am new to OpenJPA, but not new to the concept of persistence layers. (I have used Hibernate and TopLink in the past, but only for small proof-of-concept applications.) I have recently started an OpenJPA proof-of-concept application, with the goal of gaining experience with OpenJPA and the DataCache and QueryCache features of OpenJPA in particular. So far, I am very impressed with OpenJPA, and I think it is a high-quality, feature-rich, open source product. Anyway, here are my two questions: 1.) Under the heading Known issues with PostgreSQL, it says: Floats and doubles may lose precision when stored. (http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_postgresql.html#dbsupport_postgresql_issues) This sounds a bit scary, and it worries me. Question: Is this still a problem with OpenJPA 1.2.1? If yes, in what version of OpenJPA will this be resolved? 2.) The same issue is listed under Known issues with SQL Server: Floats and doubles may lose precision when stored. (http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_sqlserver.html#dbsupport_sqlserver_issues) Again, is this still a problem with OpenJPA 1.2.1? If yes, in what version of OpenJPA will this be resolved? My sincere thanks go to the OpenJPA team, for building this open source product! At the moment, I am using the following software stack for my proof-of-concept application: Persistence: OpenJPA version 1.2.1 Database: Postgresql 8.3 OS: Ubuntu 9.04 Java: JDK 1.6 IDE: Netbeans 6.8 App Server: OpenEJB 3.1.2 Regards Riaan South Africa -- View this message in context: http://n2.nabble.com/Known-issues-Floats-and-doubles-may-lose-precision-when-stored-tp4265454p4265454.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Known issues - Floats and doubles may lose precision when stored.
I'm no expert on this but I find OpenJPA 1.2.1 works just fine on ProgresSQL when I use specific notation @Column(columnDefinition=DOUBLE UNSIGNED,precision=10,scale=6, nullable=false) private double rate = 0.00; If I don't use the column definition it's a mess, same issue I find on MySQL 5.x and OpenJPA 1.2.1 My 2c! Chris -Original Message- From: Riaan [mailto:riaan.potgie...@corefreight.com] Sent: Thursday, 7 January 2010 7:41 PM To: users@openjpa.apache.org Subject: Known issues - Floats and doubles may lose precision when stored. Hi, I am new to OpenJPA, but not new to the concept of persistence layers. (I have used Hibernate and TopLink in the past, but only for small proof-of-concept applications.) I have recently started an OpenJPA proof-of-concept application, with the goal of gaining experience with OpenJPA and the DataCache and QueryCache features of OpenJPA in particular. So far, I am very impressed with OpenJPA, and I think it is a high-quality, feature-rich, open source product. Anyway, here are my two questions: 1.) Under the heading Known issues with PostgreSQL, it says: Floats and doubles may lose precision when stored. (http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_postgresql.ht ml#dbsupport_postgresql_issues) This sounds a bit scary, and it worries me. Question: Is this still a problem with OpenJPA 1.2.1? If yes, in what version of OpenJPA will this be resolved? 2.) The same issue is listed under Known issues with SQL Server: Floats and doubles may lose precision when stored. (http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_sqlserver.htm l#dbsupport_sqlserver_issues) Again, is this still a problem with OpenJPA 1.2.1? If yes, in what version of OpenJPA will this be resolved? My sincere thanks go to the OpenJPA team, for building this open source product! At the moment, I am using the following software stack for my proof-of-concept application: Persistence: OpenJPA version 1.2.1 Database: Postgresql 8.3 OS: Ubuntu 9.04 Java: JDK 1.6 IDE: Netbeans 6.8 App Server: OpenEJB 3.1.2 Regards Riaan South Africa -- View this message in context: http://n2.nabble.com/Known-issues-Floats-and-doubles-may-lose-precision-when -stored-tp4265454p4265454.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Cache Hit-Rate Statistics
Hi, I am new to Apache OpenJPA, but not new to the concept of persistence layers in Java. (I have played a little bit with Hibernate and TopLink in the past, ...without paying any attention to their cache schemes at the time.) After beginning to understand the value of having an *extended* data cache and query cache, I was drawn to Apache OpenJPA, because of the DataCache and QueryCache features built into it. I am busy writing my first proof-of-concept application using OpenJPA, and I have written some Java code to interrogate the DataCache and QueryCache instances at run-time. I find this very interesting, and the goal is to gather *Cache Hit-Rate Statistics* from a running application. What I would like to see, are the following four metrics: Data Cache Hit Count: Data Cache Miss Count: Query Cache Hit Count: Query Cache Miss Count: In order to obtain values for the above four metrics, I downloaded the OpenJPA 1.2.1 source code, and hacked in counters, and modified the source code to update (increment) the counters when necessary. This worked for me, and it gave me the information that I was looking for, but my solution is (obviously) not ideal, because of the following reasons: a.) Any newer version of OpenJPA will not contain my hacks, and I would have to modify the source code again. b.) Because I don't fully understand the OpenJPA source code, my modification may not be optimal. (This is an understatement.) Although it works, and it gives me the answers I was looking for, I really don't feel that confident about my source code changes. c.) I suspect my changes may not even work properly the moment there are more than one EntityManager or Persistence Unit in the same JVM. {I say this, because my counters are defined as static attributes on some of the OpenJPA classes. This is bad, I know.} Anyway, here are my questions: 1.) Is there currently a proper and correct way of obtaining values for the above four cache performance metrics, that I am interested in, in order to monitor a running application? 2.) If there is currently no standard way in OpenJPA to get values for these cache performance metrics, what is the chance that the OpenJPA developers could add these in, so that these metrics can be used by all OpenJPA users in the future? 3.) I guess what I am asking for, is probably not part of the Java EE Persistence API specifications. What I am suggesting, is additional features for Apache OpenJPA, ...if it is not already there. How does other people feel about adding these features to the OpenJPA cache classes? I would like to hear some thoughts on this from other users as well. Just a few comments from my side: A.] Database roundtrips are expensive, and it is a great win whenever a database roundtrip can be avoided. (This is obviously a great benefit of having data cache and query cache providers.) B.] Because cache-hits are so precious, it makes good sense to monitor cache-hits and cache-misses in a running application. The application developer could write functions to extract these performance metrics on demand. C.] I would love to see Cache Performance Metrics (as listed above) as a standard feature of OpenJPA, to be used by all OpenJPA users. D.] I plan to use the persistence context in the *Extended* mode, as opposed to per transaction or per session. In other words, for my application, I want the data cache and the query cache to be available throughout the full life cycle of the application back-end. This way, the data cache and the query cache can be *shared* by *all* the application users. This will hopefully save a lot of database roundtrips. E.] Apache OpenJPA looks like a high-quality, feature-rich, open source product. My thanks go out to the OpenJPA developers! Regards Riaan South Africa -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4266362.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Known issues - Floats and doubles may lose precision when stored.
Hi Chris, Thank you for the good advice!! I will certainly do as you suggested. Regards Riaan -- View this message in context: http://n2.nabble.com/Known-issues-Floats-and-doubles-may-lose-precision-when-stored-tp4265454p4266421.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Known issues - Floats and doubles may lose precision when stored.
On Thu, Jan 7, 2010 at 6:24 AM, C N Davies c...@cndavies.com wrote: I'm no expert on this but I find OpenJPA 1.2.1 works just fine on ProgresSQL when I use specific notation @Column(columnDefinition=DOUBLE UNSIGNED,precision=10,scale=6, nullable=false) private double rate = 0.00; If I don't use the column definition it's a mess The manual [1] states that columnDefinition, precision, and scale are used for database creation (DDL generation). I'm wondering if you have the database column correctly does that prevent precision loss or is there value truncation of some kind before going to the database. [1] http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/jpa_overview_mapping_column.html -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
RE: Known issues - Floats and doubles may lose precision when stored.
Well I haven't fully tested all possible cases, but my app works to 4 decimal places so I use the column definition shown below (6 places) and I do not get rounding issues any more. It was a big problem for me when I first started using OpenJPA a year or so ago because I am back calculating tax on low value high qty items. Chris -Original Message- From: Daryl Stultz [mailto:da...@6degrees.com] Sent: Friday, 8 January 2010 12:30 AM To: users@openjpa.apache.org Subject: Re: Known issues - Floats and doubles may lose precision when stored. On Thu, Jan 7, 2010 at 6:24 AM, C N Davies c...@cndavies.com wrote: I'm no expert on this but I find OpenJPA 1.2.1 works just fine on ProgresSQL when I use specific notation @Column(columnDefinition=DOUBLE UNSIGNED,precision=10,scale=6, nullable=false) private double rate = 0.00; If I don't use the column definition it's a mess The manual [1] states that columnDefinition, precision, and scale are used for database creation (DDL generation). I'm wondering if you have the database column correctly does that prevent precision loss or is there value truncation of some kind before going to the database. [1] http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/jpa_ overview_mapping_column.html -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
Re: Cache Hit-Rate Statistics
Hi, 1.) Is there currently a proper and correct way of obtaining values for the above four cache performance metrics, that I am interested in, in order to monitor a running application? Basic L2 Cache statistics are available on later version of OpenJPA [1]. You can download [2] fairly stable nightly builds or 2-0.0-SNAPSHOT versions for this facility. [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_cache_statistics [2] http://openjpa.apache.org/downloads.html Regards -- Pinaki Riaan wrote: Hi, I am new to Apache OpenJPA, but not new to the concept of persistence layers in Java. (I have played a little bit with Hibernate and TopLink in the past, ...without paying any attention to their cache schemes at the time.) After beginning to understand the value of having an *extended* data cache and query cache, I was drawn to Apache OpenJPA, because of the DataCache and QueryCache features built into it. I am busy writing my first proof-of-concept application using OpenJPA, and I have written some Java code to interrogate the DataCache and QueryCache instances at run-time. I find this very interesting, and the goal is to gather *Cache Hit-Rate Statistics* from a running application. What I would like to see, are the following four metrics: Data Cache Hit Count: Data Cache Miss Count: Query Cache Hit Count: Query Cache Miss Count: In order to obtain values for the above four metrics, I downloaded the OpenJPA 1.2.1 source code, and hacked in counters, and modified the source code to update (increment) the counters when necessary. This worked for me, and it gave me the information that I was looking for, but my solution is (obviously) not ideal, because of the following reasons: a.) Any newer version of OpenJPA will not contain my hacks, and I would have to modify the source code again. b.) Because I don't fully understand the OpenJPA source code, my modification may not be optimal. (This is an understatement.) Although it works, and it gives me the answers I was looking for, I really don't feel that confident about my source code changes. c.) I suspect my changes may not even work properly the moment there are more than one EntityManager or Persistence Unit in the same JVM. {I say this, because my counters are defined as static attributes on some of the OpenJPA classes. This is bad, I know.} Anyway, here are my questions: 1.) Is there currently a proper and correct way of obtaining values for the above four cache performance metrics, that I am interested in, in order to monitor a running application? 2.) If there is currently no standard way in OpenJPA to get values for these cache performance metrics, what is the chance that the OpenJPA developers could add these in, so that these metrics can be used by all OpenJPA users in the future? 3.) I guess what I am asking for, is probably not part of the Java EE Persistence API specifications. What I am suggesting, is additional features for Apache OpenJPA, ...if it is not already there. How does other people feel about adding these features to the OpenJPA cache classes? I would like to hear some thoughts on this from other users as well. Just a few comments from my side: A.] Database roundtrips are expensive, and it is a great win whenever a database roundtrip can be avoided. (This is obviously a great benefit of having data cache and query cache providers.) B.] Because cache-hits are so precious, it makes good sense to monitor cache-hits and cache-misses in a running application. The application developer could write functions to extract these performance metrics on demand. C.] I would love to see Cache Performance Metrics (as listed above) as a standard feature of OpenJPA, to be used by all OpenJPA users. D.] I plan to use the persistence context in the *Extended* mode, as opposed to per transaction or per session. In other words, for my application, I want the data cache and the query cache to be available throughout the full life cycle of the application back-end. This way, the data cache and the query cache can be *shared* by *all* the application users. This will hopefully save a lot of database roundtrips. E.] Apache OpenJPA looks like a high-quality, feature-rich, open source product. My thanks go out to the OpenJPA developers! Regards Riaan South Africa - Pinaki -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4267778.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Cache Hit-Rate Statistics
Hi Pinaki, Thank you very much for this pointer! I am glad to see that the OpenJPA team has already thought of this! I will certainly look at these new features that are available in OpenJPA 2.0. Regards Riaan -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4267976.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Known issues - Floats and doubles may lose precision when stored.
I found that care needs to be taken when using Floats, Doubles, BigDecimal, etc... OpenJPA seemed to work in most cases when I was using existing table definitions but I can't say that OpenJPA always generated the proper tables when using synchronize mappings. One oddity/problem I came across had to do with performing arithmetic inside a select on DB2 (and maybe derby). I don't have my notes infront of me right now, but I will open a JIRA for the problems I found sometime here. On Thu, Jan 7, 2010 at 11:37 AM, C N Davies c...@cndavies.com wrote: Well I haven't fully tested all possible cases, but my app works to 4 decimal places so I use the column definition shown below (6 places) and I do not get rounding issues any more. It was a big problem for me when I first started using OpenJPA a year or so ago because I am back calculating tax on low value high qty items. Chris -Original Message- From: Daryl Stultz [mailto:da...@6degrees.com] Sent: Friday, 8 January 2010 12:30 AM To: users@openjpa.apache.org Subject: Re: Known issues - Floats and doubles may lose precision when stored. On Thu, Jan 7, 2010 at 6:24 AM, C N Davies c...@cndavies.com wrote: I'm no expert on this but I find OpenJPA 1.2.1 works just fine on ProgresSQL when I use specific notation @Column(columnDefinition=DOUBLE UNSIGNED,precision=10,scale=6, nullable=false) private double rate = 0.00; If I don't use the column definition it's a mess The manual [1] states that columnDefinition, precision, and scale are used for database creation (DDL generation). I'm wondering if you have the database column correctly does that prevent precision loss or is there value truncation of some kind before going to the database. [1] http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/jpa_ overview_mapping_column.htmlhttp://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/jpa_%0Aoverview_mapping_column.html -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com -- Thanks, Rick
Re: Cache Hit-Rate Statistics
Hi Riaan, Apache OpenJPA looks like a high-quality, feature-rich, open source product. My thanks go out to the OpenJPA developers! Good to know that you have found OpenJPA useful. I plan to use the persistence context in the *Extended* mode, as opposed to per transaction or per session. In other words, for my application, I want the data cache and the query cache to be available throughout the full life cycle of the application back-end. By definition, DataCache or L2 cache lifetime is bound to persistence unit (a.k.a EntityManagerFactory) and not to a persistence context (a.k.a EntityManager). Extended mode refers to lifetime of L1 cache which is not the same as L2 cache. You can find some discussion on their differences in [1]. [1] http://ppoddar.blogspot.com/2009/10/l2-cache-in-jpa-20-and-openjpa-plug-in.html Riaan wrote: Hi, I am new to Apache OpenJPA, but not new to the concept of persistence layers in Java. (I have played a little bit with Hibernate and TopLink in the past, ...without paying any attention to their cache schemes at the time.) After beginning to understand the value of having an *extended* data cache and query cache, I was drawn to Apache OpenJPA, because of the DataCache and QueryCache features built into it. I am busy writing my first proof-of-concept application using OpenJPA, and I have written some Java code to interrogate the DataCache and QueryCache instances at run-time. I find this very interesting, and the goal is to gather *Cache Hit-Rate Statistics* from a running application. What I would like to see, are the following four metrics: Data Cache Hit Count: Data Cache Miss Count: Query Cache Hit Count: Query Cache Miss Count: In order to obtain values for the above four metrics, I downloaded the OpenJPA 1.2.1 source code, and hacked in counters, and modified the source code to update (increment) the counters when necessary. This worked for me, and it gave me the information that I was looking for, but my solution is (obviously) not ideal, because of the following reasons: a.) Any newer version of OpenJPA will not contain my hacks, and I would have to modify the source code again. b.) Because I don't fully understand the OpenJPA source code, my modification may not be optimal. (This is an understatement.) Although it works, and it gives me the answers I was looking for, I really don't feel that confident about my source code changes. c.) I suspect my changes may not even work properly the moment there are more than one EntityManager or Persistence Unit in the same JVM. {I say this, because my counters are defined as static attributes on some of the OpenJPA classes. This is bad, I know.} Anyway, here are my questions: 1.) Is there currently a proper and correct way of obtaining values for the above four cache performance metrics, that I am interested in, in order to monitor a running application? 2.) If there is currently no standard way in OpenJPA to get values for these cache performance metrics, what is the chance that the OpenJPA developers could add these in, so that these metrics can be used by all OpenJPA users in the future? 3.) I guess what I am asking for, is probably not part of the Java EE Persistence API specifications. What I am suggesting, is additional features for Apache OpenJPA, ...if it is not already there. How does other people feel about adding these features to the OpenJPA cache classes? I would like to hear some thoughts on this from other users as well. Just a few comments from my side: A.] Database roundtrips are expensive, and it is a great win whenever a database roundtrip can be avoided. (This is obviously a great benefit of having data cache and query cache providers.) B.] Because cache-hits are so precious, it makes good sense to monitor cache-hits and cache-misses in a running application. The application developer could write functions to extract these performance metrics on demand. C.] I would love to see Cache Performance Metrics (as listed above) as a standard feature of OpenJPA, to be used by all OpenJPA users. D.] I plan to use the persistence context in the *Extended* mode, as opposed to per transaction or per session. In other words, for my application, I want the data cache and the query cache to be available throughout the full life cycle of the application back-end. This way, the data cache and the query cache can be *shared* by *all* the application users. This will hopefully save a lot of database roundtrips. E.] Apache OpenJPA looks like a high-quality, feature-rich, open source product. My thanks go out to the OpenJPA developers! Regards Riaan South Africa - Pinaki -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4268214.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Known issues - Floats and doubles may lose precision when stored.
I found that care needs to be taken when using Floats, Doubles, BigDecimal, etc... OpenJPA seemed to work in most cases when I was using existing table definitions but I can't say that OpenJPA always generated the proper tables when using synchronize mappings. Actually there's http://issues.apache.org/jira/browse/OPENJPA-213 which is for database generation - decimals always have precision = 10 and scale = 0. In our case, we're waiting for a final OpenJPA 2.0 to fix it, as our app will remain in development for some time. -- Luis Fernando Planella Gonzalez
About generated source in openjpa-kernel
Hi All, I checked out svn branch 0.9.7-r547073 revision 724510. When I try to do mvn package -DskipTests I get the following exception : C:\openJPA\0.9.7-r547073_r724510\openjpa-kernel\target\generated-source s\javacc\org\apache\openjpa\kernel\jpql\org\apache\openjpa\kernel\jpql\JPQL.java :[9262,24] generics are not supported in -source 1.4 (try -source 1.5 to enable generics) private java.util.Listint[] jj_expentries = new java.util.ArrayListint[]() ; Looks like javacc-maven-plugin inside openjpa-kernel/pom.xml is getting the latest javacc plugin which is using generics to generate the source code. To resolve the issue, I had to add version2.5/version for javacc-maven-plugin to openjpa-kernel/pom.xml. Should I open a JIRA and check in the above change (or) is there a better solution for this issue ? Regards, Ravi. -- View this message in context: http://n2.nabble.com/About-generated-source-in-openjpa-kernel-tp4268662p4268662.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Cache Hit-Rate Statistics
Hi Pinaki, Thank you very much for this information. I must admit, I did not realize there were two distinct caches (L1 and L2). Furthermore, I am not that familiar with JPA 2.0 yet. (I will look into it.) As you say in your article: Everyone loves cache, and I am certainly excited about it. I can feel that I still need to learn quite a bit about JPA (v1.0 and v2.0), and therefore I appreciate your pointers greatly! Thank you very much for your support. Regards Riaan -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4268700.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: About generated source in openjpa-kernel
Hi Ravi, Adding the version is the right way to go, thanks for finding it. -mike On Thu, Jan 7, 2010 at 2:42 PM, Ravi P Palacherla ravi.palache...@oracle.com wrote: Hi All, I checked out svn branch 0.9.7-r547073 revision 724510. When I try to do mvn package -DskipTests I get the following exception : C:\openJPA\0.9.7-r547073_r724510\openjpa-kernel\target\generated-source s\javacc\org\apache\openjpa\kernel\jpql\org\apache\openjpa\kernel\jpql\JPQL.java :[9262,24] generics are not supported in -source 1.4 (try -source 1.5 to enable generics) private java.util.Listint[] jj_expentries = new java.util.ArrayListint[]() ; Looks like javacc-maven-plugin inside openjpa-kernel/pom.xml is getting the latest javacc plugin which is using generics to generate the source code. To resolve the issue, I had to add version2.5/version for javacc-maven-plugin to openjpa-kernel/pom.xml. Should I open a JIRA and check in the above change (or) is there a better solution for this issue ? Regards, Ravi. -- View this message in context: http://n2.nabble.com/About-generated-source-in-openjpa-kernel-tp4268662p4268662.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
empty collections
Hi, I have a bidirectional many-to-many relationship between two entities. Each entity references a collection of the other entity. I import data, then retrieve entities with a query. However, when I refer to an entity's collection, its size is always 0 (eg, group.getUsers().size () is 0). I look into the db and the join table is filled correctly. I restart the app, and then the same entity correctly returns the collection. That is, group.getUsers().size() is now 0 and I can access the collection's elements. I am wondering is this is a known pattern and there is an a-ha out there. Otherwise OpenJPA is working great! Thanks, chris
How to map optional joins without having to define optional intermediate entities?
Let's say that I have an entity called Category with a name field. It's mapped to a table called CATEGORY and the NAME column. This part works fine. Now I'm trying to add a mapping for a secondary table, called CATEGORY_ES which has rows corresponding to many of the rows in CATEGORY, but not all of them. This table also has a NAME column, but it's in Spanish, instead of English. I originally thought I would map CATEGORY_ES as a secondary-table, but that appears to not be possible, as there are rows in CATEGORY that don't have corresponding rows in CATEGORY_ES. When I do a query for rows that don't have a row in CATEGORY_ES, the query fails. I originally had a name field, so I was thinking I would make that a transient field, and also have nameEN and nameES, and do a translation after properties are set to determine what name is. I might have to make the Category entity have a one-to-one field called categoryES, of type CategoryES (mapped to the obvious table) which will either be set or not. Does this look like the best way to do this?
Re: How to map optional joins without having to define optional intermediate entities?
Hi, On Jan 7, 2010, at 2:57 PM, KARR, DAVID (ATTCINW) wrote: Let's say that I have an entity called Category with a name field. It's mapped to a table called CATEGORY and the NAME column. This part works fine. Now I'm trying to add a mapping for a secondary table, called CATEGORY_ES which has rows corresponding to many of the rows in CATEGORY, but not all of them. This table also has a NAME column, but it's in Spanish, instead of English. I originally thought I would map CATEGORY_ES as a secondary-table, but that appears to not be possible, as there are rows in CATEGORY that don't have corresponding rows in CATEGORY_ES. When I do a query for rows that don't have a row in CATEGORY_ES, the query fails. I originally had a name field, so I was thinking I would make that a transient field, and also have nameEN and nameES, and do a translation after properties are set to determine what name is. I might have to make the Category entity have a one-to-one field called categoryES, of type CategoryES (mapped to the obvious table) which will either be set or not. Does this look like the best way to do this? Yes. A OneToOne with cardinality 0..1 sounds like it exactly matches your description. The main requirement is that there is a column in the CATEGORY table that is the target of a foreign key in the CATEGORY_ES table. The semantics of a one to one relationship are very similar to a secondary table so most of your application logic should work. Just check the reference for null (don't assume that the other side exists). If you query the CATEGORY_ES table you can go back to the CATEGORY table, but not necessarily the other way. Craig Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp!
Re: ClassNotFoundException on persisting serialized class
Thanks . I had the same issue and this solved the problem. But it would be nice if OpenJPA can handle this and throw exception rather than setting value to null.. 4000 chars is also seems like quite a small value for field like BLOB CLOB.. Jon Solanu wrote: Pinaki Poddar wrote: You are annotating getter/setter, but their names do not match bean-style. public com.MyData getMyData() {...} public void setMetadataList(com.MyData myData) {...} Miss typed it when posting. The problem ended up being that the object I was trying to insert was larger than 4000 characters. Adding the following to the persistence.xml fixed it. Its fairly odd that no errors were thrown when the data was flushed to the database, it just set the values to null and continued. property name=openjpa.jdbc.DBDictionary value=oracle(maxEmbeddedBlobSize=-1,maxEmbeddedClobSize=-1)/ -- View this message in context: http://n2.nabble.com/ClassNotFoundException-on-persisting-serialized-class-tp2433282p4270817.html Sent from the OpenJPA Users mailing list archive at Nabble.com.