Andrey, The main issue with returning version is sending redundant information over the wire. What if we added a method IgniteCache.localEntry(K) which would return a local entry instance with a version. You would only be able to invoke this method on the server node (not client).
Would this work for you? D. On Fri, Dec 18, 2015 at 8:23 AM, Andrey Kornev <[email protected]> wrote: > Denis, > > I'm not suggesting to have every cache read operation return a CacheEntry. > The "classical" GridGain used to have a getEntry(key) method that was very > useful. The current version of Ignite provides virtually no way of > obtaining a cache entry except thru an iterator, or using an EntryProcessor > invocation which seems more like a hack. > > As for the question of what's stored in Ignite cache and the pre-compute, > it is really an off-topic. It just came about as we were looking for a way > to work around the issue with Ignite query not returning cache entries' > version numbers in the result iterator. (There is now a ticket that > addresses this issue: https://issues.apache.org/jira/browse/IGNITE-2202 > )This is when we realized that there is no longer any way in Ignite to > retrieve the CacheEntry by its key. > > But for the sake of completeness I quickly go over the entire use case, > because it seems I wasn't clear enough in the previous post. > > Ignite cache holds the data entries that are used as the input into some > expensive computation. The data in the cache gets updated from time to > time, the computation only needs to be re-run > - on-demand -- when a user asks for the computed value and > - the pre-computed value is obsolete -- the source cache data has been > updated since the last time the value was computed. > > Otherwise, we return the pre-computed value. Note that we don't want to > rerun the computation for each cache update! Only when the users asks for > it. > > I hope it make it more clear now. > > Thanks > Andrey > > > Subject: Re: Missing ways to get access to Ignite CacheEntry > > To: [email protected] > > From: [email protected] > > Date: Fri, 18 Dec 2015 13:44:16 +0300 > > > > Hi Andrey, > > > > I got you, thanks for the clarification. > > > > So since you're storing a computed value in some local data structure > > what is stored in the Ignite cache as a value in such a case? There > > should be something. > > Why don't you (or can't you) store a version identifier in that value > > that is located in the Ignite cache? This should work perfectly well for > > you use-case. > > > > Personally I'm against adding CacheEntry to a response of every get like > > operation that happens over a cache (get, getAll, SQL & Scan queries). > > This will add extra size to every response and only in rare cases > > someone will benefit from it. > > However, what if we add a special configuration parameter to > > CacheConfiguration that will manage whether CacheEntry has to be passed > > as a part of a response or not? Igniters, what do you think on this? > > > > > > Regards, > > Denis > > > > > > On 12/17/2015 9:09 AM, Andrey Kornev wrote: > > > Denis,In this case I used the term "caching" in general sense, meaning > saving the computed value for later. I didn't mean the Ignite cache.Sorry > about the confusion.Andrey > > > _____________________________ > > > From: Denis Magda <[email protected]> > > > Sent: Wednesday, December 16, 2015 9:48 PM > > > Subject: Re: Missing ways to get access to Ignite CacheEntry > > > To: <[email protected]> > > > > > > > > > Hi Romain, > > > > > > I'm a bit confused cause initially you saying that > > > > > > /The value is computed on first access and it is then cached > > > > > > /and then you add that > > > > > > /One constraint is that the computed value is not serializable. // > > > / > > > > > > > > > Ignite won't be able to store a value of cache if serialization is > not > > > supported for it by some reason. > > > > > > Please clarify here. Probably I'm missing something from your > description. > > > > > > -- > > > Denis > > > > > > On 12/16/2015 6:21 PM, Andrey Kornev wrote: > > > > Romain > > > > > > > > I suggest you be very careful using the invoke() functionality. As > explained in this posting (and the follow-ups) > > > > > http://mail-archives.apache.org/mod_mbox/ignite-dev/201511.mbox/%3CSNT147-W14D2736E1374450B685721CF000%40phx.gbl%3E > > > > the correct usage of the invoke() may be difficult, to put it > politely. > > > > > > > > @Denis Very briefly, the use case is "conditional re-compute". > There is a pretty expensive computation that needs to be applied to each > entry on demand. The value is computed on first access and it is then > cached along with the current version of the cache entry. The value must > be recomputed on next access only if the entry has been modified. > > > > > > > > If anyone has a better idea how to achieve something like that, > please do share! One constraint is that the computed value is not > serializable. > > > > > > > > Cheers > > > > Andrey > > > > > > > >> Subject: Re: Missing ways to get access to Ignite CacheEntry > > > >> To: [email protected] > > > >> From: [email protected] > > > >> Date: Wed, 16 Dec 2015 16:11:48 +0300 > > > >> > > > >> Romain, > > > >> > > > >> If it's implemented this way for now it doesn't mean that we can't > > > >> enhance the API for other use cases ;) > > > >> As I said presently it's supported for limited number of methods > mostly > > > >> by performance reasons. > > > >> > > > >> Please go ahead and try invoke/invokeAll and if it doesn't work > fine for > > > >> you we can keep discussing what to do next. > > > >> > > > >> Regards, > > > >> Denis > > > >> > > > >> On 12/16/2015 1:53 PM, Romain Gilles wrote: > > > >>> Hi Denis, > > > >>> Thanks for you replay. And sorry to not double check it before. > I see that > > > >>> if I want to work with CacheEntry, I need to use the invoke > method in order > > > >>> to return the CacheEntry. This is the way I should do it. It > sounds like > > > >>> complicated for "just" getting an entry. But if you say this is > the way I > > > >>> will do it like that. I was just think that it could be a common > use case > > > >>> and therefore provide it as a shortcut. > > > >>> > > > >>> Thanks, > > > >>> > > > >>> Romain. > > > >>> > > > >>> Le mer. 16 déc. 2015 à 11:34, Denis Magda <[email protected]> > a écrit : > > > >>> > > > >>>> Hi Romain, > > > >>>> > > > >>>> As the current documentation of > org.apache.ignite.cache.CacheEntry > > > >>>> states it's possible to get a reference to CacheEntry and its > version > > > >>>> only for methods that are executed over local data set stored > on a node. > > > >>>> Among such methods are invoke & invokeAll and randomEntry. > > > >>>> > > > >>>> You probably can get a CacheEntry and its non null version when > a cache > > > >>>> iterator is in use but the version will be 'null', as far as I > remember, > > > >>>> for those entries that are loaded from remote nodes. > > > >>>> Presently Ignite doesn't transfer the version from remote nodes > as a > > > >>>> part of response by perform reasons. > > > >>>> > > > >>>> Please elaborate more on your particular use case and what API > you would > > > >>>> like to add in order to support it. > > > >>>> > > > >>>> -- > > > >>>> Denis > > > >>>> > > > >>>> On 12/16/2015 12:58 PM, Romain Gilles wrote: > > > >>>>> Hi Igniters, > > > >>>>> I'm looking for a way to get access to the Ignite CacheEntry. > For now > > > >>>> this > > > >>>>> is the ways I found: > > > >>>>> > > > >>>>> - Through the queris > > > >>>>> - Through jsr 107 Cache Iterable > > > >>>>> - Through jsr 107 Cache itterator > > > >>>>> - Through IgniteCache::randomEntry() > > > >>>>> > > > >>>>> If I remember correctly it was possible to get the CacheEntry > from a > > > >>>> given > > > >>>>> key in old version of gridgain community > > > >>>>> version: GridCacheProjection::entry(K key) GridCacheEntry<K,V> > > > >>>>> I think it could be a good to introduce this feature at > IgniteCache > > > >>>> level. > > > >>>>> Or maybe there is an other way to do it. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> > > > >>>>> Romain. > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > >
