[hibernate-dev] Attribute laziness and caching

[Steve Ebersole]

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