Vladimir, 1. Comparator can be included to ignite and may be configured with a string like: "this.a > other.a && (this.b + 1 < other.b)". String may be parsed and interpreted. We can also have JavaScript comparator. 2. Agree, but cannot say how to avoid it. Actually, comparison logic may not be needed on client. 3. I would avoid requirement to have any classes on server. Let's think how to support object comparison without forcing class presence. This will make Ignite cluster more flexible.
Frankly speaking, object comparison can be avoided and replaced by inlining the fields and defining group index. Am I right? --Yakov 2016-03-01 9:23 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > Val, > > Comparator has two problems from user perspective: > 1) User will be obligated to have comparator classes on servers. > BinaryMarshaller was designed to avoid this. > 2) Code duplication - user will have to support two implementations - one > for deserialized form, and one for binary form. > > As it appears that user is going to have some kind of classes on the > server, why not simply deserialize cache objects and perform normal > comparison? > > Vladimir. > > On Tue, Mar 1, 2016 at 9:06 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Why can’t we simply compare the binary arrays? > > > > On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Igniters, > > > > > > We currently have a pretty serious limitation for binary objects: they > > can > > > be used as SQL fields and can't be indexed, because we don't know how > to > > > compare them. And it seems to me that it can be easily fixed by adding > an > > > optional comparator to BinaryConfiguration and BinaryTypeConfiguration: > > > > > > public void setComparator(Comparator<BinaryObject> comparator) > > > > > > Are there any pitfalls that I'm missing? > > > > > > -Val > > > > > >
