Well, One of the disadvantages of rich APIs is that they are very hard to learn due to massive amount of methods on them. On top of that, rich cache entry API is still not rich enough to support all the IgniteCache API, so it is still a subset.
However, I completely agree with your point about a need to pass a context or the cache instance itself. This is not convenient, and moreover, we won't have full freedom to do it because of JCache spec. I have just noticed that most JCache APIs, including Cache and Cache.Entry, have this method: *<T> T unwrap(java.lang.Class<T> clazz);* How about we use these methods to replace the need for a context? For example, ---- *Ignite ignite = entry.unwrap(Ignite.class);* *IgniteCache cache = entry.unwrap(IgniteCache.class);* *IgniteCache.Entry entry = entry.unwrap(IgniteCache.Entry.class);* ---- Thoughts? D. On Sat, Jan 17, 2015 at 9:10 AM, Vladimir Ozerov <[email protected]> wrote: > I think our rich entry concept is a good design because user do not have to > pass context (i.e. cache) to any place where he want to use the entry. > Instead, entry encapsulates the cache. > If we remove it, instead of simply passing GridCacheEntry between the > methods, user will have to either pass both cache and key or bother with > adding cache as a field to any class which is expected to use cache > entries. The latter approach is not a problem with DI frameworks like > Spring, but still yields in more code comparing to GridCacheEntry. > > Can we simply made our GridCacheEntry implementing JCache interface, so > that user could cast/unwrap it to GridCacheEntry if absolute JCache > implementation independence is not required? > > > > On Sat, Jan 17, 2015 at 6:14 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > I want to get some opinions about IGNITE-96: > > https://issues.apache.org/jira/browse/IGNITE-96 > > > > Cache.Entry from JCache spec has a very small API and is, in fact, not > much > > different from Java Map.Entry. In GridGain however, the GridCacheEntry > API > > has many additional methods, mainly duplicating functionality from the > > GridCache API. > > > > I personally like the JCache approach and don't think we need extra > methods > > on the cache entry API. User can always get this functionality from the > > IgniteCache API. > > > > Can anyone think of a good reason to have additional methods on the cache > > entry API? > > > > D. > > >
