I certainly agree that it looks a bit complicated. I suppose it's a
trade-off between similarity to Hibernate versus improving code
quality were we find the opportunity.
Btw, the problem in NH-2961 is that since 3.2, in
Loader.ListUsingQueryCache(), the DoList() call will return a list of
arrays such as { fetchedAlias, rootEntity } while the resultTypes
parameter
will be only { itype-for-rootEntity }. This is what causes the
IndexOutOfRangeException below PutResultInQueryCache().
/Oskar
2012/12/30 Julian Maughan <[email protected]>:
> Hello Oskar
>
> Maybe there is a need for it, but I can't see a reason for the approach
> taken in Hibernate - with the CacheableResultTransformer.
>
> If GetResultColumnOrRow() always returned a consistent result (an object[])
> that doesn't depend on the existence of a ResultTransformer, couldn't the
> StandardQueryCache be adjusted to handle this? The intent would be to make
> the CriteriaLoader, QueryLoader and CustomLoader more consistent in how they
> behave - they are currently returning different 'shape' results depending
> whether a transformer exists or not. All transformation would be done in
> GetResultList() - after caching concerns - and would be applied to an
> object[]. If you can wait, I will try to show you some code...assuming my
> theory holds water when I try to implement it :)
>
> Regards
> Julian
>
> On 30 December 2012 00:31, Oskar Berggren <[email protected]> wrote:
>>
>> 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.
>
>
