Re: [hibernate-dev] Attribute laziness and caching
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?