ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: changes in marshaling and SQL
Date Fri, 26 Jun 2015 12:41:12 GMT
Btw, not having classes on servers makes impossible affinity routed
computations. In this case all data should be processed on clients and then
marhsalled and send back to clients. Thoughts?

--Yakov

2015-06-26 14:16 GMT+03:00 Sergi Vladykin <sergi.vladykin@gmail.com>:

> 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 <sboikov@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 <
> dsetrakyan@apache.org
> > >
> > wrote:
> >
> > > Can we repurpose CacheObject API for this?
> > >
> > > On Fri, Jun 26, 2015 at 1:55 AM, Vladimir Ozerov <vozerov@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 <
> sboikov@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 <
> > > > dsetrakyan@apache.org
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > On Thu, Jun 25, 2015 at 11:21 PM, Semyon Boikov <
> > > sboikov@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 <
> > > > > > dsetrakyan@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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message