Interesting - I did try your workaround and didn't see a difference, but probably I did something incorrectly. I'll play with it some more.
For the superclass we were using @MappedSuperclass with single table inheritance strategy. I traced through the select process in debug mode and saw that it skipped over a number of the fields. In JDBCStoreManager.selectSubclassMappings() there's a comment: // select all subclass mappings that match the fetch configuration // and whose table is in the list of those selected so far; this // way we select the max possible without selecting any tables that // aren't present in all possible query matches; a special case // is made for mappings that use 2-part selects that aren't // explicitly *not* in the default so that they can get their // primary table data I interpret this to mean that since we don't know the type of the subclass in advance, we don't know if we'll need to join a particular table or not, so only select from the ones we're already joined with. ________________________________________ From: Henno Vermeulen <he...@huizemolenaar.nl> Sent: Tuesday, July 22, 2014 12:03 AM To: users@openjpa.apache.org Subject: RE: Avoiding N+1 on collection in recursive relation First issue: We don't use the data cache either! If I recall correctly, exactly for the same reason: for different use cases we may use different fetch plans for the same entity. (Actually at our client-side we have actually implement our home-made cache - backed by ehache - that uses the fetchplan name as part of the cache key.). I was speaking about the entities in the persistence context. This is a non-shared first-level cache of the EntityManager that is only kept for the duration of one transaction. As far as I know this is always used by default and cannot be turned off. I believe it is also used internally by JPA. When multiple database queries are done in one transaction, JPA can use this temporary cache to find referenced entities that have already been loaded during the same transaction, even if you don't have shared second-level cache turned on. So if your performance issue is important I suggest giving my suggestion a try! Second issue: I haven't seen that before. Perhaps this depends on the inheritance strategy. We have had no problems with InheritanceType.TABLE_PER_CLASS but we have had issues with an incorrect query being generated when using InheritanceType.JOINED so we don't use that. Depending on your use case you may also use @MappedSuperclass which has been working fine for us. Regards, Henno -- _____________ David Minor
