In my case CacheProjection is used in private classes. I was thinking that our agreed plan was to remove CacheProjection totally, not only from public API. This is why I was confused how to fix the bug I found.
On Mon, Feb 9, 2015 at 7:48 PM, Dmitriy Setrakyan <[email protected]> wrote: > Can you provide a bit more information? We should still be removing > CacheProjection from public API, right? > > D. > > On Mon, Feb 9, 2015 at 7:55 AM, Vladimir Ozerov <[email protected]> > wrote: > > > I've just was told that we will not remove cache projection. So I just > > fixed cache projection code. > > I have no more questions here. > > > > On Mon, Feb 9, 2015 at 6:52 PM, Yakov Zhdanov <[email protected]> > > wrote: > > > > > > > > > > > http://docs.spring.io/spring/docs/current/spring-framework-reference/html/cache.html > > > > > > -- > > > Yakov Zhdanov, Director R&D > > > *GridGain Systems* > > > www.gridgain.com > > > > > > 2015-02-09 18:25 GMT+03:00 Dmitriy Setrakyan <[email protected]>: > > > > > > > Vova, > > > > > > > > Can you explain what a Spring dynamic cache is and where do we use > it? > > > > > > > > D. > > > > > > > > On Mon, Feb 9, 2015 at 7:21 AM, Vladimir Ozerov < > [email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I see that if GridCacheProjectionImpl.removeAll() is called, entry > > > filter > > > > > is ignored. As a result, all keys are removed from undelying cache > > > > instead > > > > > of clearing only projection keys. > > > > > > > > > > This problems is evident when working with Spring dynamic caches: > > > > evicting > > > > > all entries in one cache results in removal of entries in all other > > > > dynamic > > > > > caches. > > > > > > > > > > This is a bug. But how are we going to fix it taking in count that > > > cache > > > > > projection is going to be removed? > > > > > > > > > > Vladimir. > > > > > > > > > > > > > > >
