cool. I'm reviewing the code, and it looks simple to fix.
The bug is that in DistributedStoreQuery.executeQuery, it is getting
confused between isUnique and isAggregate. It needs to do some fancy
aggregation work for aggregated queries ( avg, sum, count, etc ), but it
doesn't need to do anything for unique queries. Alas, it is trying to
use UniqueResultObjectProvider for "unique" as well as "aggregated"
queries, where in reality that class assumes and only deals with
"aggregated" queries. That is the real bug, in that this class will
only return an empty array if applied to any queries without projections..
Though UniqueResultObjectProvider is the current root cause, looking
over the code, the code should not be treating Unique queries any
different, since they are mostly dealt with within
QueryImpl.singleResult. So as long as we don't try to garble them by
treating them as aggregate queries, it should be fixed.
but basically what I'm planning on changing, is to rename
UniqueResultObjectProvider to something like
AggregatingMergedResultObjectProvider, then changing
DistributedStoreQuery.executeQuery to only modify aggregate queries,
while dealing with "unique" queries like normal..
if ( expression is aggregate ) {
use AggregatingMergedResultObjectProvider.
}
if ( sorting ) {
use OrderingMergedResultObjectProvider
} else {
use MergedResultObjectProvider
}
Pinaki Poddar wrote:
Any hints Pinaki?
The simple answer is Query execution takes different path when it is has to
return a single result.
Personally, I would like a query to be executed in the same way and then the
facade getSingleResult() should determine whether the selected result is
unique or not and return to user appropriately.
thoughts?
