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. >
