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