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 |
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 > |
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 > > > |
In reply to this post by dsetrakyan
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 > > > |
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 > > > > > > |
In reply to this post by Valentin Kulichenko
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 |
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 > > |
Free forum by Nabble | Edit this page |