[hibernate-dev] 6.0 - ResultTransformer

[Steve Ebersole]

On Tue, Sep 13, 2016 at 9:55 PM Gail Badner <gbadner at 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.