[hibernate-dev] Attribute laziness and caching

[Steve Ebersole]

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 <steve at 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 at 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 at 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?
>>>
>>