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 < [email protected]> 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 >
