Multiple layer of group by

Question

hello all:
I learned how to use coherence Aggregator functions, this is an example:
GroupAggregator aggregator = GroupAggregator.createInstance(prop, new BigDecimalAverage(target));
Map<Object, Object> ret = aggregate(filter, aggregator);it works fine, the problem is that if I want to group by on more than one property, what is the best practise? Say, I want to group by on "date" and "currency", to figue out the average of "cash", and what is the proper data structure to hold the result?
Thanks,
John

Answer 1

Johnny_hunter wrote:
Robert: Thanks for the response. You are right, my aggregate method threw an exception showing I was wrong using DecimalSum ( or other Decimal-prefix aggregation)
java.io.IOException: decimal value exceeds IEEE754r 128-bit rangeI was wondering why this exception go silent until I used a try/catch block around the suspicious code? Is it a runtime exception or checked exception?
Thanks,
JohnHi John,
It is a checked exception, but exceptions from serialization are wrapped into a RuntimeException because the NamedCache methods do not declare checked exceptions, as any exception occuring during those methods indicate abnormal conditions.
In this case, you were trying to use a BigDecimal which could not be represented with 128bit. There is a problem that you are not able to substitute your own serializers for BigDecimal and BigInteger at the moment because they are handled as special cases, thus you cannot provide a serializer which would not be restricted by using the POF T_DECIMAL128 and T_INT128 types which POF uses for BigDecimal and BigInteger.
I filed an improvement request filed for it a while ago which got the JIRA id COH-5308 and which when implemented would allow you to use your own PofSerializers for BigDecimal and BigInteger, but I believe it is not implemented/released yet and I believe it is not scheduled for 3.7.x.
As your test shows, some other out-of-the-box functionality which cannot be worked around (out-of-the-box BigDecimal aggregators) is hindered by it, so it makes it a bit more serious than just not being able to transmit user created BigDecimals, so if you file a service request to release the fix for COH-5308 in a patch to 3.7, you may be able to get it. But don't take that as a promise, that is just my opinion that if you have an actual use case for it, it may raise the prioritization of it.
It is possible to override type resolution for objects so you could plug in your own ConfigurablePofContext subclass instead of ConfigurablePofContext which handles these two classes as a special case before falling back to the super implementation but it would be a bit less performant than if Coherence handled it on its own without an additional method delegation.
Best regards,
Robert
Edited by: robvarga on Apr 18, 2012 4:19 PM
Edited by: robvarga on Apr 18, 2012 4:23 PM