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.ht...
On Fri, Nov 13, 2015 at 3:41 PM Steve Ebersole <steve(a)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 <steve(a)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 <steve(a)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?
>>
>