Planning to use OpenJPA in a new application development and am spending some time to review options of how it could be implemented.
I hope to use the rich domain model that has has already been developed for the application. This model implements a lookup object that has a few attributes (lookUpType, lookUpValue, sortOrder, disabled). In the domain model, any lookup is mapped as a one-to-many relationship from the main object to the lookup object. In the database model, these will be implemented as foreign key lookups to a lookup table. Pre JPA and Hibernate, if using hand coded SQL, I would read these foreign keys as int/long and then resolve to their values using a pre-initialised cache. (for performance etc.). Using OpenJPA, the default mechanism would load the lookup objects from the LookUp table either eagerly when the main object is read from the database, of lazily when the lookup is accessed. Neither seems like a good solution from a performance point of view. The eager load strategy would create a large SQL statement with multiple joins to the LookUp table (there could be multiple lookups in the main object). The lazy load strategy would cause multiple individual SQL statements when the lookup objects were referenced. I have not had a chance to do much experimentation - from reading it looks like there may be some ways to optimise using a combination of pinning all the lookup objects into cache, loading of the main object with a lazy load strategy for the lookup objects, and then specifically referencing all of the lookups so that they are retrieved by JPA (from the cache) - possibly with the use of a fetch group. This sounds like a lot of overhead (performance and developer) for a simple problem. Since this seems to be a common design issue so I assume someone more experienced than me has come up with a good solution. Can anybody help? -- View this message in context: http://n2.nabble.com/Retrieving-data-from-Lookup-Tables-tp1109950p1109950.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
