> On 20 Sep 2013, at 21:38, Emmanuel Bernard <[email protected]> wrote: > > Well, I have always wanted a way to only read some keys from a FGAM. Sort of > like a projection.
Yep, the key filter would do just that :-) > >> On 20 sept. 2013, at 21:14, Randall Hauch <[email protected]> wrote: >> >> IMO, the primary benefit of the FGAM is that you can aggregate your entries >> into a single entry that is a real aggregate: read the map and you get all >> the FGAM's entries in one fell swoop. IIUC, your proposal loses this >> capability for a single read of all aggregate parts. Is that right? >> >>> On Sep 20, 2013, at 11:49 AM, Mircea Markus <[email protected]> wrote: >>> >>> Hi, >>> >>> Most of the FGAM functionality can be achieved with grouping, by using the >>> FGAM key as a grouping key. >>> The single bit that seems to be missing from grouping to equivalent the >>> functionality of FGAM is obtaining all the entries under a single group. >>> IOW a method like: >>> >>> Map<K,V> groupedKeys = Cache.getGroup(groupingKey, KeyFilter); >>> >>> This can be relatively easily implemented with the same performance as an >>> AtomicMap lookup. >>> >>> Some other differences worth mentioning: >>> - the cache would contain more entries in the grouping API approach. Not >>> sure if this is really a problem though. >>> - in order to assure REPEATABLE_READ, the AM (including values) is brought >>> on the node that reads it (does't apply to FGAM). Not nice. >>> - people won't be able to lock an entire group (the equivalent of locking a >>> AM key). I don't think this is a critical requirement, and also can be >>> worked around. Or added as a built in function if needed. >>> >>> I find the idea of dropping FGAM and only using grouping very tempting: >>> - there is logic duplication between Grouping and (FG)AM (the locality, >>> fine grained locking) that would be removed >>> - FGAM and AM semantic is a bit ambiguous in corner cases >>> - having a Cache.getGroup does make sense in a general case >>> - reduce the code base >>> >>> What do people think? >>> >>> Cheers, >>> -- >>> Mircea Markus >>> Infinispan lead (www.infinispan.org) >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
