Binary comparator

[Valentin Kulichenko]

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

[dsetrakyan]

Why can’t we simply compare the binary arrays?

On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko <
[hidden email]> 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
>

[Valentin Kulichenko]

The comparator is optional, so we need to have some kind of default
behavior anyway. But I'm sure that it will not work in many cases, because
user can't even control the order of fields used for comparison.

On Mon, Feb 29, 2016 at 10:06 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Why can’t we simply compare the binary arrays?
>
> On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko <
> [hidden email]> 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
> >
>

[Vladimir Ozerov]

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 <[hidden email]>
wrote:

> Why can’t we simply compare the binary arrays?
>
> On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko <
> [hidden email]> 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
> >
>

[yzhdanov]

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 <[hidden email]>:

> 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 <[hidden email]>
> wrote:
>
> > Why can’t we simply compare the binary arrays?
> >
> > On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko <
> > [hidden email]> 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
> > >
> >
>

[Andrey Kornev]

Val,

Just to clarify, are you talking about indexing a whole binary object as a single entity (rather than individually indexing its fields)? If so, how would one then use such "field" in a SQL query?

Thanks
Andrey

> From: [hidden email]
> Date: Mon, 29 Feb 2016 21:18:39 -0800
> Subject: Binary comparator
> To: [hidden email]
>
> 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

     

[Valentin Kulichenko]

Andrey,

Any comparable object can be used as a field. You can execute a query like
'my_object > ?' and provide the instance of the object as an argument. Of
course, this is not something that everyone does, but it can be useful in
some cases. And now it's fully supported with JDK or optimized
serialization, but not with binary format.

I agree with all points, the simple approach doesn't really work here. And
I like the idea of a string-based configuration, I will try to provide
design in the ticket.

-Val

On Tue, Mar 1, 2016 at 7:42 AM, Andrey Kornev <[hidden email]>
wrote:

> Val,
>
> Just to clarify, are you talking about indexing a whole binary object as a
> single entity (rather than individually indexing its fields)? If so, how
> would one then use such "field" in a SQL query?
>
> Thanks
> Andrey
>
> > From: [hidden email]
> > Date: Mon, 29 Feb 2016 21:18:39 -0800
> > Subject: Binary comparator
> > To: [hidden email]
> >
> > 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
>
>