Re: [hibernate-dev] 6.0 - ResultTransformer
On Tue, Sep 13, 2016 at 9:55 PM Gail Badner <gbadner(a)redhat.com> wrote:
Sorry for the late response. I've been looking through the fix
for
HHH-5163 [1] to jog my memory.
Here are some reasons why CacheableResultTransformer is important when
caching query results:
1) The same SQL can be generated when associations are joined as when
associations are fetched, but what gets cached is different. The cached
results exclude fetched associations. QueryKey needs to contain the proper
CacheableResultTransformer to indicate which tuple elements are cached to
distinguish the differing results.
Just to be clear... Those 2 cases *do not* generate the same SQL. In fetch
case the SELECT clause includes the association columns, in the
non-fetch-join case it doe not.
But I understand what you mean. And with 6.0 this is no longer a concern
since all of the selections (the SQL selections) are cached. Along with
the fact that we know the "fetch graph" now in 6.0 wrt that cached data we
can easily (well "easily" is relative) rebuild the full graph.
2) IIRC, the tuple elements that got cached by the legacy Criteria
and HQL
were inconsistent, and I believe that in some cases the ResultTransformer
was applied before caching the value, which added to problems assembling
the query results (HHH--2463). CacheableResultTransformer ensured that what
got cached was consistent (excluding fetched values), and ensured that rows
were untransformed (padded with nulls where fetches were) and
re-transformed (if necessary) by a specified transformer as necessary.
Right. This is it. And with 6.0 because we now cache the actual JDBC
values (meaning transformations are applied "on top of" the cached values)
this is no longer a concern.
I added lots of tests for this change, so I think we will find out
quickly
if something gets broken.
Sweet! Although hopefully the tests do not assert that fetched
associations are no longer present. That was not the case pre-6.x but is
no longer true as discussed above.
Steve, I'm not completely following your discussion. Some pseudocode would
help.
I gave psuedo code above and in the Jira I linked.