On 7/30/2015 4:36 PM, Dmitriy Setrakyan wrote:
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[email protected]> wrote:
Igniters,
I've been working on the task that will let the user to retrieve version
related information for a particular Cache.Entry object.
All the details are here: https://issues.apache.org/jira/browse/IGNITE-946
VersionedEntry of a given Cache.Entry can be retrieved by a call to
'Cache.Entry.unwrap(VersionedEntry.class)'.
I've already fully supported 'unwrap' for Cache.Entry when it is returned
from:
- Cache.invoke();
- Cache.invokeAll();
- IgniteCache.randomEntry();
The following entry points are left:
- Cache.iterator();
- IgniteCache.localEntries().
However, I doubt that it makes sense to support these two last methods.
In my understanding a use case scenario of VersionedEntry is the
following: the user get a VersionedEntry for a particular key(s) using
Cache.invoke, keeps it and then compares with other VersionEntries for the
same key retrieved later.
I don't think that the user will iterate over a cache using
Cache.iterator() or IgniteCache.localEntries() in order to get a version,
especially in production.
Denis, what is the reason for not supporting a version on an entry at all
times? Is there a specific performance issue or slow down you are concerned
with?
Dmitriy, to support it at the level of Cache.iterator() and
IgniteCache.localEntries() requires a lot of modifications in Ignite
code. That's why I'm interested whether it makes sense to do it or not
before start coding.
Can't say how the modifications will affect performance, from the first
view they shouldn't.
--
Denis
What do you think? Do you see any other real life scenarios I'm missing?
--
Denis
