withKeepIgniteObject behavior

[Alexey Goncharuk <al...@gmail.com>]

Igniters,

As a part of work on IGNITE-950 [1] ticket we wanted to implement a
functionality which would allow users to plug their own implementation of
IgniteObject, which in turn would allow to introspect objects for fields
without deserialization and use of reflection.

The design draft is available on wiki [2]. Comments are highly appreciated.
One of the good use-cases of this feature will be an ability to index and
query JSON objects.

Now, as a part of preliminary work for this ticket I was looking at current
implementation of Portable objects (not released, in private API) and found
that cache modifier withKeepPortable() (will be renamed to
withKeepIgniteObjects) is not working properly. Namely, this modifier is
not honored in entry processors and interceptors for transactional cache.

Now, consider the following code:

cacheA = ignite.cache("A");
cacheB = ignite.cache("B").withKeepIgniteObjects();

try (Transaction tx = ignite.transactions.txStart()) {
    cacheA.invoke(key1, new EP());
    cacheB.invoke(key2, new EP2());

    tx.commit();
}

This code will require to store and transmit over the network a per-cache
map of withKeepIgniteObjects flag. It is not hard to implement, but I looks
like it is an additional overhead that we might not need. So to speak, same
thing is not currently supported for withSkipStore flag.

My question is - do we want/need to support this use-case?

[1] https://issues.apache.org/jira/browse/IGNITE-950
[2]
https://cwiki.apache.org/confluence/display/IGNITE/Pluggable+IgniteObjects

Re: withKeepIgniteObject behavior

[Semyon Boikov <sb...@gridgain.com>]

Alexey,

We already implemented 'per-transaction entry' behavior  for 'skipStore'
flag and IgniteTxEntry already have 'flags' field where 'keepPortable' flag
can be added.

On Mon, Oct 19, 2015 at 5:58 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Igniters,
>
> As a part of work on IGNITE-950 [1] ticket we wanted to implement a
> functionality which would allow users to plug their own implementation of
> IgniteObject, which in turn would allow to introspect objects for fields
> without deserialization and use of reflection.
>
> The design draft is available on wiki [2]. Comments are highly appreciated.
> One of the good use-cases of this feature will be an ability to index and
> query JSON objects.
>
> Now, as a part of preliminary work for this ticket I was looking at current
> implementation of Portable objects (not released, in private API) and found
> that cache modifier withKeepPortable() (will be renamed to
> withKeepIgniteObjects) is not working properly. Namely, this modifier is
> not honored in entry processors and interceptors for transactional cache.
>
> Now, consider the following code:
>
> cacheA = ignite.cache("A");
> cacheB = ignite.cache("B").withKeepIgniteObjects();
>
> try (Transaction tx = ignite.transactions.txStart()) {
>     cacheA.invoke(key1, new EP());
>     cacheB.invoke(key2, new EP2());
>
>     tx.commit();
> }
>
> This code will require to store and transmit over the network a per-cache
> map of withKeepIgniteObjects flag. It is not hard to implement, but I looks
> like it is an additional overhead that we might not need. So to speak, same
> thing is not currently supported for withSkipStore flag.
>
> My question is - do we want/need to support this use-case?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-950
> [2]
> https://cwiki.apache.org/confluence/display/IGNITE/Pluggable+IgniteObjects
>

Re: withKeepIgniteObject behavior

[Dmitriy Setrakyan <ds...@apache.org>]

Alexey,

I am not sure what will be passed into the EntryProcessor, specifically in
your example, EP and EP2. Will it be an instance of IgniteObject or a
deserialized instance? In my view, we must support both, because server
side may not, and most likely, will not have client-side class definitions.

D.

On Mon, Oct 19, 2015 at 7:58 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Igniters,
>
> As a part of work on IGNITE-950 [1] ticket we wanted to implement a
> functionality which would allow users to plug their own implementation of
> IgniteObject, which in turn would allow to introspect objects for fields
> without deserialization and use of reflection.
>
> The design draft is available on wiki [2]. Comments are highly appreciated.
> One of the good use-cases of this feature will be an ability to index and
> query JSON objects.
>
> Now, as a part of preliminary work for this ticket I was looking at current
> implementation of Portable objects (not released, in private API) and found
> that cache modifier withKeepPortable() (will be renamed to
> withKeepIgniteObjects) is not working properly. Namely, this modifier is
> not honored in entry processors and interceptors for transactional cache.
>
> Now, consider the following code:
>
> cacheA = ignite.cache("A");
> cacheB = ignite.cache("B").withKeepIgniteObjects();
>
> try (Transaction tx = ignite.transactions.txStart()) {
>     cacheA.invoke(key1, new EP());
>     cacheB.invoke(key2, new EP2());
>
>     tx.commit();
> }
>
> This code will require to store and transmit over the network a per-cache
> map of withKeepIgniteObjects flag. It is not hard to implement, but I looks
> like it is an additional overhead that we might not need. So to speak, same
> thing is not currently supported for withSkipStore flag.
>
> My question is - do we want/need to support this use-case?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-950
> [2]
> https://cwiki.apache.org/confluence/display/IGNITE/Pluggable+IgniteObjects
>