ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Missing ways to get access to Ignite CacheEntry
Date Mon, 21 Dec 2015 18:19:23 GMT
Couple of points. 

First,  if it were up to me, I'd keep the API simple & consistent by always providing
the version as defined by Ignite's CacheEntry interface, regardless whether it's the query
who produces the entry or a specialized method like getEntry(). Which node is going to consume
the data -- a "client" or "server" -- should not matter either. In this case, however a concern
about perceived performance losses due to  the version overhead has apparently trumped any
API integrity and consistency concerns.

Second, given the first point, here's what I think we could do to keep everybody (the performance
kids and the consistency/integrity old-farts) happy. )))

1) getEntry(K) unconditionally always returns a valid version regardless whether it's called
from a client or server. In fact, the only reason to ever use this method is to get the entry
version. I'd even suggest going one step further and have the getEntry() method return Ignite's
CacheEntry interface rather than JCache's Cache.Entry (only to be immediately unwrapped to
Ignite's CacheEntry).

2) for queries, provide an option on the Ignite's Query class (say, setIncludeEntryVersion(boolean))
that would control whether the query should send the version back. By default, it'd be "false"
as to have no impact on performance. More advanced users ;) would still be able to enjoy API
consistency by setting that option to "true".


> From: dsetrakyan@apache.org
> Date: Mon, 21 Dec 2015 08:30:02 -0800
> Subject: Re: Missing ways to get access to Ignite CacheEntry
> To: dev@ignite.apache.org
> On Mon, Dec 21, 2015 at 12:36 AM, Denis Magda <dmagda@gridgain.com> wrote:
> >
> >
> > On 12/21/2015 11:15 AM, Dmitriy Setrakyan wrote:
> >
> >> On Mon, Dec 21, 2015 at 12:11 AM, Denis Magda <dmagda@gridgain.com>
> >> wrote:
> >>
> >> Why it shouldn't work?
> >>> If client receives an entry that has a reference to the entry with
> >>> version, transferred from a server as well as a part of the response,
> >>> then
> >>> unwrap(...) should work.
> >>> Isn't this feasible to implement?
> >>>
> >>> The reason is consistency. If getEntry(…) can be unwrapped on the client
> >> side, then all the query results should be un-wrappable as well, which
> >> means that we have to always carry the cache version, even if user does
> >> not
> >> need it.
> >>
> > The proposal is to add getEntry(...) method exactly for the cases when
> > someone needs an entry with a version on a client.
> > In all other cases (queries, etc.) the version won't be a part of a
> > response.
> >
> > Right, this is inconsistent but if to document everything well then the
> > user will only benefit from the new getEntry(...) method.
> > CacheEntry with version is already can be unwrapped from specific places
> > that are listed in its documentation. We will just broaden the list.
> >
> Romain, Andrey, can you please comment?
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message