..@gmail.com
> > Date: Mon, 29 Feb 2016 21:18:39 -0800
> > Subject: Binary comparator
> > To: dev@ignite.apache.org
> >
> > Igniters,
> >
> > We currently have a pretty serious limitation for binary objects: they
> can
> > be used as SQL fields a
6 21:18:39 -0800
> Subject: Binary comparator
> To: dev@ignite.apache.org
>
> 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
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 ne
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 app
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
wrote:
> Why can’t we simply compare
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 kno
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 BinaryTypeConfigura
