Can we repurpose CacheObject API for this? On Fri, Jun 26, 2015 at 1:55 AM, Vladimir Ozerov <voze...@gridgain.com> wrote:
> +1 for Semen point. > > Is it really popular scenario when user does not have classes on server? > Looks like a corner case for me. > > On Fri, Jun 26, 2015 at 11:40 AM, Semyon Boikov <sboi...@gridgain.com> > wrote: > > > Ok, in this case we need to design this wrapper API, also this should be > > somehow configurable so user still should be able to work with real > > classes. > > > > On Fri, Jun 26, 2015 at 10:50 AM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > On Thu, Jun 25, 2015 at 11:21 PM, Semyon Boikov <sboi...@gridgain.com> > > > wrote: > > > > > > > Just want to remind that deserialized value is needed not only for > > > > indexing, now deserialized value is passed to EntryProcessors, cache > > > > interceptors, cache store, cache events, scan query, continuous query > > > > filter, so if user uses one of these features class still will be > > needed > > > on > > > > servers. > > > > > > > > > > Semyon, I don't think we need to deserialize in this case, but rather > > pass > > > some CacheObject wrapper around the binary format. > > > > > > D. > > > > > > > > > > > > > > On Thu, Jun 25, 2015 at 7:28 PM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > As a part of Denis Magda's work on IGNITE-950 > > > > > <https://issues.apache.org/jira/browse/IGNITE-950>, we are not > going > > > to > > > > > require that server side nodes have class definitions of user > > classes, > > > as > > > > > we are going to keep them in the binary format. This is a BIG deal, > > as > > > > now > > > > > users will not have to copy their application JAR files to the > server > > > > > nodes. > > > > > > > > > > However, this change also affects the way we support queries. > > > Previously, > > > > > we simply extracted fields using reflection to do index lookups, > but > > > now > > > > we > > > > > cannot use reflection, since we do not have class definitions on > the > > > > > servers anymore. > > > > > > > > > > As a result, the following restrictions are going to be introduced > to > > > the > > > > > query processing: > > > > > > > > > > > > > > > 1. @QuerySqlField annotation can't be set to a getter method > > > anymore, > > > > > only to fields. > > > > > 2. Comparable on _key and _value type will not work anymore. > > > However, > > > > > "_key" and "_value" types are auto-generated and mostly used > > > > internally > > > > > by > > > > > Ignite itself. > > > > > > > > > > > > > > > Generally, I believe that both (1) and (2) are not a big deal. > > > However, I > > > > > would like to confirm that for the (2), we can still retrieve and > > sort > > > > > primitive values and Strings natively. > > > > > > > > > > Serj, given that you are working on the query changes, can you > > confirm > > > > the > > > > > (2)? > > > > > > > > > > D. > > > > > > > > > > > > > > >
