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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
