Handling of result transformers was changed in NHibernate in
bf8056a8c32f0a7dbc99e94fd1a4727c8fe3cdd2 to fix NH-1090, NH-1344 and
NH-2673 (2011-05-02). Plus some later adjustments.

This was briefly discussed here, with some passing comments from Fabio
that seem to imply some problem with the Hibernate changes. Though
there really isn't enough context to figure out exactly what fixes
Fabio meant.
https://groups.google.com/forum/?fromgroups=#!searchin/nhibernate-development/resulttransformer/nhibernate-development/DSsPksZ4S2M/discussion

The NHibernate changes, however, caused the NH-2961 regression
affecting the interaction between second level cache and result
transformers when an eager load or join alias is present. To fix this,
we can revert the relevant pieces of
bf8056a8c32f0a7dbc99e94fd1a4727c8fe3cdd2, and instead port the
refactored transformer handling from Hibernate. This would be:

ef46a4efb77a7028500801a9db2a2c398e7e6b7f
HHH-5424 HHH-5425 : Put ResultTransformer in QueryKey only if data is
transformed; PropertyAccessException when caching 1 result per row

dc00c4dcde1bae399a9350bd4a13f9a2a449f6c3
HHH-5163 : ClassCastException caching results using ResultTransformer


Can anyone remember if these Hibernate changes was rejected for some
reason or if they were just unnoticed? Or if there is some other bad
thing with these? Otherwise I'm gonna go ahead and apply this for NH4.

The ported changes are here:
https://nhibernate.jira.com/browse/NH-3363
https://github.com/oskarb/nhibernate-core/tree/NH3363

The main idea seem to be to delay the CriteriaLoader's application of
the user-specified result transformer until after caching, but to do
so in a manner that only tries to cache the data actually required by
the result transformer.

The code on the branch passes all test cases (with a few expected
adjustments) and also passes the previously failing tests for NH-2961.


/Oskar

Reply via email to