Sergey, Classes do not disappear, they become optional. Without having classes, certain things, like CacheInterceptor may not work, but not everyone uses it anyway.
The work you are doing is to make sure that we are not deserializing objects only for indexing. For your purposes, I think you should assume that there are no class definitions on the server side. D. On Fri, Jun 26, 2015 at 4:16 AM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote: > Guys, > > Now I see that idea of not having classes on server node is definitely a > corner case. Why do we even want that other than for interoperability with > other platforms like .NET? I think we should carefully reconsider the whole > approach before we brake something. > > Sergi > > 2015-06-26 13:13 GMT+03:00 Semyon Boikov <sboi...@gridgain.com>: > > > I don't think so, this is internal API and now it doesn't even have > method > > to get field by name. > > > > On Fri, Jun 26, 2015 at 12:02 PM, Dmitriy Setrakyan < > dsetrak...@apache.org > > > > > wrote: > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
