So here is what I plan to do since I have heard no replies... I went ahead and migrated the tests using enhancement+caching to use the testing runtime enhancement capabilities Luis and I have built. On top of that I am going to start adding more detailed assertions.
It does seem to me that even the old behavior is inaccurate from reading the documentation. I ported a test specifying include = "non-lazy" for the caching. Based on the documentation[1] I fully expected this to only cache any of the attributes marked as non-lazy. However it ends up caching all of the attributes. Based on this research, I also have no idea why this boolean is actually written to the CacheEntry; the value is generally applicable to the persister, so storing it into the cache per-item is wasteful. Similarly, I am not really grokking the point in having that value on EntityEntry either. I may end up simply completely removing it from there. [1] https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/performance.html#performance-cache-mapping On Fri, Nov 13, 2015 at 3:41 PM Steve Ebersole <st...@hibernate.org> wrote: > I worry that this stuff may just not work too. The tests that tested this > stuff all expected the the involved entities to be build time enhanced > prior to launching the tests. Which of course they aren't. So all the > tests for enhancement + caching have effectively been skipped for years. > > On Fri, Nov 13, 2015 at 11:15 AM Steve Ebersole <st...@hibernate.org> > wrote: > >> Gah, hit send too soon :) >> >> This comes up because I am working on the idea of lazy attribute fetch >> groups. This means that the simple boolean that we used to store is no >> longer going to be sufficient. This ties in with the discussion I started >> the other day about using attribute indexes versus attribute names. As it >> stands now, this boolean needs to become a Collection of Strings (attribute >> names) which is a big change perf wise. This affects one of the classes we >> have worked hard to minimize in recent months: EntityEntry. >> >> >> On Fri, Nov 13, 2015 at 11:08 AM Steve Ebersole <st...@hibernate.org> >> wrote: >> >>> In reworking some of the support for bytecode-enhanced laziness, I >>> started thinking deeper about this idea of partial caching of such >>> entities. >>> >>> First and foremost, why do we even allow this? Essentially what happens >>> is that we allow a user to partially load an entity, and then stick that >>> partial state into the cache (along with a boolean indicating that the >>> state is partial). >>> >>> I guess I can somewhat see the usefulness of this, but what really gets >>> me confused is how the caching of this data works.. As far as I can tell, >>> we never re-cache the entity state after the uninitialized portions have >>> been initialized. So the cached representation, iiuc, continues to be the >>> partial representation. If we continue to allow the partial representation >>> to be cached, wouldn't we want to update the cache entry with the >>> initialized portions once they become available? >>> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
