You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Steven Jacobs <sj...@ucr.edu> on 2015/08/19 19:32:25 UTC
Strange Comparison Allowed
This is currently working in master:
create type CSXType as closed {
id: int32,
csxid: string
}
create dataset CSX(CSXType) primary key id;
for $b in dataset('CSX')
where $b.id > point("3,5")
return $b;
Is this supposed to be working?
Steven
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
Yes. Till. You are correct, too. :-) So, here is the conclusion: Steven's
query returns FALSE for each comparison since INT and POINT are not
comparable types. It's not the result of byte-to-byte comparison.
Best,
Taewoo
On Wed, Aug 19, 2015 at 3:31 PM, Till Westmann <ti...@apache.org> wrote:
> I remember having those discussions and arguing for the byte-by-byte
> comparison for internal needs, but I also don’t remember why we would do
> this for other comparisons. If somebody remembers (or has written it down),
> could you remind us?
>
> However, I do think that it’s a good idea to allow the byte-by-byte
> comparison of order by in Wail’s case as long as we don’t have a need for a
> more specific comparison of lists.
>
> Cheers,
> Till
>
> > On Aug 19, 2015, at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
> >
> > This all sounds somewhat wrong to me! It's not what I remember from
> design
> > discussions of old... I don't think we should be doing byte by byte
> > comparison between disparate types. Why would users want or expect that?
> > Note that I'm talking about predicate cases - not internal needs like
> order
> > by or routing of data.
> > On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
> >
> > wrote:
> >
> >> @Steven
> >> Index rewrite will not fire in this case, because of type mismatch.
> Hence
> >> it will fallback to non-indexed query results.
> >>
> >> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
> >>
> >>> @Steven: I never tried. However, it's worthwhile to check. If the query
> >>> semantic is correct, the optimizer will try to utilize the index
> >> regardless
> >>> of its type. My guess is, at the end, byte-by-byte comparison will
> occur.
> >>>
> >>> Best,
> >>> Taewoo
> >>>
> >>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
> >> wrote:
> >>>
> >>>> I think this is because the serialized versions of the list have their
> >>>> lengths among the beginning bytes, so this would make sense, since we
> >>> don't
> >>>> have a comparator for lists.
> >>>>
> >>>> @Taewoo-What about the case of an index search? Is it okay to pass the
> >>>> wrong type to the search (which will obviously yield unknown results)
> >>>>
> >>>> Steven
> >>>>
> >>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
> wael.y.k@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> Actually I observed some strange behavior while comparing
> >> orderedLists
> >>> in
> >>>>> the order by clause.
> >>>>>
> >>>>> Input (dataset json):
> >>>>> { "a": 1i32, "b": [ 1, "hello" ] }
> >>>>> { "a": 2i32, "b": [ 1, "hello" ] }
> >>>>> { "a": 3i32, "b": [ 1, "hi" ] }
> >>>>>
> >>>>> Query:
> >>>>> for $x in dataset json
> >>>>> order by $x.b
> >>>>> return $x
> >>>>>
> >>>>> Result:
> >>>>> { "a": 3i32, "b": [ 1, "hi" ] }
> >>>>> { "a": 1i32, "b": [ 1, "hello" ] }
> >>>>> { "a": 2i32, "b": [ 1, "hello" ] }
> >>>>>
> >>>>> it seems the behavior is comparing by the length of the list not the
> >>>> values
> >>>>> themselves? is it expected?
> >>>>>
> >>>>> But if I do something like this:
> >>>>> for $x in dataset json
> >>>>> order by $x.b[1]
> >>>>> return $x
> >>>>>
> >>>>> Result:
> >>>>> { "a": 1i32, "b": [ 1, "hello" ] }
> >>>>> { "a": 2i32, "b": [ 1, "hello" ] }
> >>>>> { "a": 3i32, "b": [ 1, "hi" ] }
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>>> Sorry. The direction of inequality operator was misleading. STRING
> >> 13
> >>>> is
> >>>>>> smaller than (<) POINT 20.
> >>>>>>
> >>>>>> Best,
> >>>>>> Taewoo
> >>>>>>
> >>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Yes. Type conversion (casting) only happens among numeric types
> >> so
> >>>> far.
> >>>>>>> Actually, since there is a type-tag, if you try to compare two
> >> non
> >>>>>> numeric
> >>>>>>> types, it stops the comparing as soon as it sees the first byte
> >>> from
> >>>>> both
> >>>>>>> side since type-tag itself has the given order (e.g., STRING 13 >
> >>>> POINT
> >>>>>>> 20). This is required for ORDER BY, too.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Taewoo
> >>>>>>>
> >>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
> >> sjaco002@ucr.edu>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I see, so we are technically allowed to compare anything to
> >>>> anything?
> >>>>>>>>
> >>>>>>>> Steven
> >>>>>>>>
> >>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
> >> wangsaeu@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> If there is no right comparator for the given types (STRING vs
> >>>>> POINT),
> >>>>>>>> then
> >>>>>>>>> it does the "byte by byte" comparison.
> >>>>>>>>>
> >>>>>>>>> Best,
> >>>>>>>>> Taewoo
> >>>>>>>>>
> >>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
> >>> sjaco002@ucr.edu
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> This is currently working in master:
> >>>>>>>>>>
> >>>>>>>>>> create type CSXType as closed {
> >>>>>>>>>> id: int32,
> >>>>>>>>>> csxid: string
> >>>>>>>>>> }
> >>>>>>>>>> create dataset CSX(CSXType) primary key id;
> >>>>>>>>>>
> >>>>>>>>>> for $b in dataset('CSX')
> >>>>>>>>>> where $b.id > point("3,5")
> >>>>>>>>>> return $b;
> >>>>>>>>>>
> >>>>>>>>>> Is this supposed to be working?
> >>>>>>>>>> Steven
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> *Regards,*
> >>>>> Wail Alkowaileet
> >>>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ildar
> >>
>
>
Re: Strange Comparison Allowed
Posted by Till Westmann <ti...@apache.org>.
I remember having those discussions and arguing for the byte-by-byte comparison for internal needs, but I also don’t remember why we would do this for other comparisons. If somebody remembers (or has written it down), could you remind us?
However, I do think that it’s a good idea to allow the byte-by-byte comparison of order by in Wail’s case as long as we don’t have a need for a more specific comparison of lists.
Cheers,
Till
> On Aug 19, 2015, at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
>
> This all sounds somewhat wrong to me! It's not what I remember from design
> discussions of old... I don't think we should be doing byte by byte
> comparison between disparate types. Why would users want or expect that?
> Note that I'm talking about predicate cases - not internal needs like order
> by or routing of data.
> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <il...@gmail.com>
> wrote:
>
>> @Steven
>> Index rewrite will not fire in this case, because of type mismatch. Hence
>> it will fallback to non-indexed query results.
>>
>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>>
>>> @Steven: I never tried. However, it's worthwhile to check. If the query
>>> semantic is correct, the optimizer will try to utilize the index
>> regardless
>>> of its type. My guess is, at the end, byte-by-byte comparison will occur.
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
>> wrote:
>>>
>>>> I think this is because the serialized versions of the list have their
>>>> lengths among the beginning bytes, so this would make sense, since we
>>> don't
>>>> have a comparator for lists.
>>>>
>>>> @Taewoo-What about the case of an index search? Is it okay to pass the
>>>> wrong type to the search (which will obviously yield unknown results)
>>>>
>>>> Steven
>>>>
>>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <wael.y.k@gmail.com
>>>
>>>> wrote:
>>>>
>>>>> Actually I observed some strange behavior while comparing
>> orderedLists
>>> in
>>>>> the order by clause.
>>>>>
>>>>> Input (dataset json):
>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>
>>>>> Query:
>>>>> for $x in dataset json
>>>>> order by $x.b
>>>>> return $x
>>>>>
>>>>> Result:
>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>
>>>>> it seems the behavior is comparing by the length of the list not the
>>>> values
>>>>> themselves? is it expected?
>>>>>
>>>>> But if I do something like this:
>>>>> for $x in dataset json
>>>>> order by $x.b[1]
>>>>> return $x
>>>>>
>>>>> Result:
>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
>>> wrote:
>>>>>
>>>>>> Sorry. The direction of inequality operator was misleading. STRING
>> 13
>>>> is
>>>>>> smaller than (<) POINT 20.
>>>>>>
>>>>>> Best,
>>>>>> Taewoo
>>>>>>
>>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> Yes. Type conversion (casting) only happens among numeric types
>> so
>>>> far.
>>>>>>> Actually, since there is a type-tag, if you try to compare two
>> non
>>>>>> numeric
>>>>>>> types, it stops the comparing as soon as it sees the first byte
>>> from
>>>>> both
>>>>>>> side since type-tag itself has the given order (e.g., STRING 13 >
>>>> POINT
>>>>>>> 20). This is required for ORDER BY, too.
>>>>>>>
>>>>>>> Best,
>>>>>>> Taewoo
>>>>>>>
>>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>> sjaco002@ucr.edu>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I see, so we are technically allowed to compare anything to
>>>> anything?
>>>>>>>>
>>>>>>>> Steven
>>>>>>>>
>>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>> wangsaeu@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> If there is no right comparator for the given types (STRING vs
>>>>> POINT),
>>>>>>>> then
>>>>>>>>> it does the "byte by byte" comparison.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Taewoo
>>>>>>>>>
>>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
>>> sjaco002@ucr.edu
>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> This is currently working in master:
>>>>>>>>>>
>>>>>>>>>> create type CSXType as closed {
>>>>>>>>>> id: int32,
>>>>>>>>>> csxid: string
>>>>>>>>>> }
>>>>>>>>>> create dataset CSX(CSXType) primary key id;
>>>>>>>>>>
>>>>>>>>>> for $b in dataset('CSX')
>>>>>>>>>> where $b.id > point("3,5")
>>>>>>>>>> return $b;
>>>>>>>>>>
>>>>>>>>>> Is this supposed to be working?
>>>>>>>>>> Steven
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Regards,*
>>>>> Wail Alkowaileet
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Ildar
>>
Re: Strange Comparison Allowed
Posted by Heri Ramampiaro <he...@gmail.com>.
Yes, that makes sense. I will leave the deep-equal as is, wrt. equality for
now then.
Thanks,
-heri
> On Aug 20, 2015, at 9:54 AM, Mike Carey <dt...@gmail.com> wrote:
>
> I'm not sure we need to define a logical ordering of those - I'd prefer not - I would just want to allow = as an operator on them. (We have other things that aren't orderable, e.g., points.) We should think of them as being kind of like points or time intervals in that sense.
>
> On 8/19/15 11:42 PM, Heri Ramampiaro wrote:
>> I can look into the extension of the deep-equal so that we can use it for ordering
>> lists and records, in addition to just returning a binary equality.
>>
>> -heri
>>
>>
>>> On Aug 20, 2015, at 12:44 AM, Mike Carey <dt...@gmail.com> wrote:
>>>
>>> Phew! And meanwhile we should incorporate Heri's work to allow meaningful
>>> non-atomic value comparisons and hash joining!
>>> On Aug 19, 2015 3:39 PM, "Taewoo Kim" <wa...@gmail.com> wrote:
>>>
>>>> Sorry for my poor memory. Mike is correct. I have checked the codebase.
>>>> Byte-to-byte comparison is should be only conducted for the order by case.
>>>> For equality operations, we do have protection. If you check
>>>> AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
>>>> checks whether the given two values are comparable first. If not, it just
>>>> return false. Therefore, in this case, INT > POINT returns FALSE. The
>>>> result is FALSE, based on the fact that INT and POINT can't be compared,
>>>> not based on the byte-by-byte level comparison.
>>>>
>>>> Best,
>>>> Taewoo
>>>>
>>>> On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
>>>>
>>>>> This all sounds somewhat wrong to me! It's not what I remember from
>>>> design
>>>>> discussions of old... I don't think we should be doing byte by byte
>>>>> comparison between disparate types. Why would users want or expect that?
>>>>> Note that I'm talking about predicate cases - not internal needs like
>>>> order
>>>>> by or routing of data.
>>>>> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
>>>>>
>>>>> wrote:
>>>>>
>>>>>> @Steven
>>>>>> Index rewrite will not fire in this case, because of type mismatch.
>>>> Hence
>>>>>> it will fallback to non-indexed query results.
>>>>>>
>>>>>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>>>>>>
>>>>>>> @Steven: I never tried. However, it's worthwhile to check. If the
>>>> query
>>>>>>> semantic is correct, the optimizer will try to utilize the index
>>>>>> regardless
>>>>>>> of its type. My guess is, at the end, byte-by-byte comparison will
>>>>> occur.
>>>>>>> Best,
>>>>>>> Taewoo
>>>>>>>
>>>>>>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
>>>>>> wrote:
>>>>>>>> I think this is because the serialized versions of the list have
>>>>> their
>>>>>>>> lengths among the beginning bytes, so this would make sense, since
>>>> we
>>>>>>> don't
>>>>>>>> have a comparator for lists.
>>>>>>>>
>>>>>>>> @Taewoo-What about the case of an index search? Is it okay to pass
>>>>> the
>>>>>>>> wrong type to the search (which will obviously yield unknown
>>>> results)
>>>>>>>> Steven
>>>>>>>>
>>>>>>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
>>>>> wael.y.k@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Actually I observed some strange behavior while comparing
>>>>>> orderedLists
>>>>>>> in
>>>>>>>>> the order by clause.
>>>>>>>>>
>>>>>>>>> Input (dataset json):
>>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>>>
>>>>>>>>> Query:
>>>>>>>>> for $x in dataset json
>>>>>>>>> order by $x.b
>>>>>>>>> return $x
>>>>>>>>>
>>>>>>>>> Result:
>>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>>>
>>>>>>>>> it seems the behavior is comparing by the length of the list not
>>>>> the
>>>>>>>> values
>>>>>>>>> themselves? is it expected?
>>>>>>>>>
>>>>>>>>> But if I do something like this:
>>>>>>>>> for $x in dataset json
>>>>>>>>> order by $x.b[1]
>>>>>>>>> return $x
>>>>>>>>>
>>>>>>>>> Result:
>>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> Sorry. The direction of inequality operator was misleading.
>>>>> STRING
>>>>>> 13
>>>>>>>> is
>>>>>>>>>> smaller than (<) POINT 20.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Taewoo
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
>>>> wangsaeu@gmail.com
>>>>>>>> wrote:
>>>>>>>>>>> Yes. Type conversion (casting) only happens among numeric
>>>> types
>>>>>> so
>>>>>>>> far.
>>>>>>>>>>> Actually, since there is a type-tag, if you try to compare
>>>> two
>>>>>> non
>>>>>>>>>> numeric
>>>>>>>>>>> types, it stops the comparing as soon as it sees the first
>>>> byte
>>>>>>> from
>>>>>>>>> both
>>>>>>>>>>> side since type-tag itself has the given order (e.g., STRING
>>>>> 13 >
>>>>>>>> POINT
>>>>>>>>>>> 20). This is required for ORDER BY, too.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Taewoo
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>>>>>> sjaco002@ucr.edu>
>>>>>>>>>> wrote:
>>>>>>>>>>>> I see, so we are technically allowed to compare anything to
>>>>>>>> anything?
>>>>>>>>>>>> Steven
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>>>>>> wangsaeu@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> If there is no right comparator for the given types
>>>> (STRING
>>>>> vs
>>>>>>>>> POINT),
>>>>>>>>>>>> then
>>>>>>>>>>>>> it does the "byte by byte" comparison.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>> Taewoo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
>>>>>>> sjaco002@ucr.edu
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> This is currently working in master:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> create type CSXType as closed {
>>>>>>>>>>>>>> id: int32,
>>>>>>>>>>>>>> csxid: string
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> create dataset CSX(CSXType) primary key id;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> for $b in dataset('CSX')
>>>>>>>>>>>>>> where $b.id > point("3,5")
>>>>>>>>>>>>>> return $b;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is this supposed to be working?
>>>>>>>>>>>>>> Steven
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> *Regards,*
>>>>>>>>> Wail Alkowaileet
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Ildar
>>>>>>
>
Re: Strange Comparison Allowed
Posted by Mike Carey <dt...@gmail.com>.
I'm not sure we need to define a logical ordering of those - I'd prefer
not - I would just want to allow = as an operator on them. (We have
other things that aren't orderable, e.g., points.) We should think of
them as being kind of like points or time intervals in that sense.
On 8/19/15 11:42 PM, Heri Ramampiaro wrote:
> I can look into the extension of the deep-equal so that we can use it for ordering
> lists and records, in addition to just returning a binary equality.
>
> -heri
>
>
>> On Aug 20, 2015, at 12:44 AM, Mike Carey <dt...@gmail.com> wrote:
>>
>> Phew! And meanwhile we should incorporate Heri's work to allow meaningful
>> non-atomic value comparisons and hash joining!
>> On Aug 19, 2015 3:39 PM, "Taewoo Kim" <wa...@gmail.com> wrote:
>>
>>> Sorry for my poor memory. Mike is correct. I have checked the codebase.
>>> Byte-to-byte comparison is should be only conducted for the order by case.
>>> For equality operations, we do have protection. If you check
>>> AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
>>> checks whether the given two values are comparable first. If not, it just
>>> return false. Therefore, in this case, INT > POINT returns FALSE. The
>>> result is FALSE, based on the fact that INT and POINT can't be compared,
>>> not based on the byte-by-byte level comparison.
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
>>>
>>>> This all sounds somewhat wrong to me! It's not what I remember from
>>> design
>>>> discussions of old... I don't think we should be doing byte by byte
>>>> comparison between disparate types. Why would users want or expect that?
>>>> Note that I'm talking about predicate cases - not internal needs like
>>> order
>>>> by or routing of data.
>>>> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
>>>>
>>>> wrote:
>>>>
>>>>> @Steven
>>>>> Index rewrite will not fire in this case, because of type mismatch.
>>> Hence
>>>>> it will fallback to non-indexed query results.
>>>>>
>>>>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>>>>>
>>>>>> @Steven: I never tried. However, it's worthwhile to check. If the
>>> query
>>>>>> semantic is correct, the optimizer will try to utilize the index
>>>>> regardless
>>>>>> of its type. My guess is, at the end, byte-by-byte comparison will
>>>> occur.
>>>>>> Best,
>>>>>> Taewoo
>>>>>>
>>>>>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
>>>>> wrote:
>>>>>>> I think this is because the serialized versions of the list have
>>>> their
>>>>>>> lengths among the beginning bytes, so this would make sense, since
>>> we
>>>>>> don't
>>>>>>> have a comparator for lists.
>>>>>>>
>>>>>>> @Taewoo-What about the case of an index search? Is it okay to pass
>>>> the
>>>>>>> wrong type to the search (which will obviously yield unknown
>>> results)
>>>>>>> Steven
>>>>>>>
>>>>>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
>>>> wael.y.k@gmail.com
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Actually I observed some strange behavior while comparing
>>>>> orderedLists
>>>>>> in
>>>>>>>> the order by clause.
>>>>>>>>
>>>>>>>> Input (dataset json):
>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>>
>>>>>>>> Query:
>>>>>>>> for $x in dataset json
>>>>>>>> order by $x.b
>>>>>>>> return $x
>>>>>>>>
>>>>>>>> Result:
>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>>
>>>>>>>> it seems the behavior is comparing by the length of the list not
>>>> the
>>>>>>> values
>>>>>>>> themselves? is it expected?
>>>>>>>>
>>>>>>>> But if I do something like this:
>>>>>>>> for $x in dataset json
>>>>>>>> order by $x.b[1]
>>>>>>>> return $x
>>>>>>>>
>>>>>>>> Result:
>>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
>>>>>> wrote:
>>>>>>>>> Sorry. The direction of inequality operator was misleading.
>>>> STRING
>>>>> 13
>>>>>>> is
>>>>>>>>> smaller than (<) POINT 20.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Taewoo
>>>>>>>>>
>>>>>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
>>> wangsaeu@gmail.com
>>>>>>> wrote:
>>>>>>>>>> Yes. Type conversion (casting) only happens among numeric
>>> types
>>>>> so
>>>>>>> far.
>>>>>>>>>> Actually, since there is a type-tag, if you try to compare
>>> two
>>>>> non
>>>>>>>>> numeric
>>>>>>>>>> types, it stops the comparing as soon as it sees the first
>>> byte
>>>>>> from
>>>>>>>> both
>>>>>>>>>> side since type-tag itself has the given order (e.g., STRING
>>>> 13 >
>>>>>>> POINT
>>>>>>>>>> 20). This is required for ORDER BY, too.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Taewoo
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>>>>> sjaco002@ucr.edu>
>>>>>>>>> wrote:
>>>>>>>>>>> I see, so we are technically allowed to compare anything to
>>>>>>> anything?
>>>>>>>>>>> Steven
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>>>>> wangsaeu@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>> If there is no right comparator for the given types
>>> (STRING
>>>> vs
>>>>>>>> POINT),
>>>>>>>>>>> then
>>>>>>>>>>>> it does the "byte by byte" comparison.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Taewoo
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
>>>>>> sjaco002@ucr.edu
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> This is currently working in master:
>>>>>>>>>>>>>
>>>>>>>>>>>>> create type CSXType as closed {
>>>>>>>>>>>>> id: int32,
>>>>>>>>>>>>> csxid: string
>>>>>>>>>>>>> }
>>>>>>>>>>>>> create dataset CSX(CSXType) primary key id;
>>>>>>>>>>>>>
>>>>>>>>>>>>> for $b in dataset('CSX')
>>>>>>>>>>>>> where $b.id > point("3,5")
>>>>>>>>>>>>> return $b;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is this supposed to be working?
>>>>>>>>>>>>> Steven
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Regards,*
>>>>>>>> Wail Alkowaileet
>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Ildar
>>>>>
Re: Strange Comparison Allowed
Posted by Heri Ramampiaro <he...@gmail.com>.
I can look into the extension of the deep-equal so that we can use it for ordering
lists and records, in addition to just returning a binary equality.
-heri
> On Aug 20, 2015, at 12:44 AM, Mike Carey <dt...@gmail.com> wrote:
>
> Phew! And meanwhile we should incorporate Heri's work to allow meaningful
> non-atomic value comparisons and hash joining!
> On Aug 19, 2015 3:39 PM, "Taewoo Kim" <wa...@gmail.com> wrote:
>
>> Sorry for my poor memory. Mike is correct. I have checked the codebase.
>> Byte-to-byte comparison is should be only conducted for the order by case.
>> For equality operations, we do have protection. If you check
>> AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
>> checks whether the given two values are comparable first. If not, it just
>> return false. Therefore, in this case, INT > POINT returns FALSE. The
>> result is FALSE, based on the fact that INT and POINT can't be compared,
>> not based on the byte-by-byte level comparison.
>>
>> Best,
>> Taewoo
>>
>> On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
>>
>>> This all sounds somewhat wrong to me! It's not what I remember from
>> design
>>> discussions of old... I don't think we should be doing byte by byte
>>> comparison between disparate types. Why would users want or expect that?
>>> Note that I'm talking about predicate cases - not internal needs like
>> order
>>> by or routing of data.
>>> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
>>>
>>> wrote:
>>>
>>>> @Steven
>>>> Index rewrite will not fire in this case, because of type mismatch.
>> Hence
>>>> it will fallback to non-indexed query results.
>>>>
>>>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>>>>
>>>>> @Steven: I never tried. However, it's worthwhile to check. If the
>> query
>>>>> semantic is correct, the optimizer will try to utilize the index
>>>> regardless
>>>>> of its type. My guess is, at the end, byte-by-byte comparison will
>>> occur.
>>>>>
>>>>> Best,
>>>>> Taewoo
>>>>>
>>>>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
>>>> wrote:
>>>>>
>>>>>> I think this is because the serialized versions of the list have
>>> their
>>>>>> lengths among the beginning bytes, so this would make sense, since
>> we
>>>>> don't
>>>>>> have a comparator for lists.
>>>>>>
>>>>>> @Taewoo-What about the case of an index search? Is it okay to pass
>>> the
>>>>>> wrong type to the search (which will obviously yield unknown
>> results)
>>>>>>
>>>>>> Steven
>>>>>>
>>>>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
>>> wael.y.k@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Actually I observed some strange behavior while comparing
>>>> orderedLists
>>>>> in
>>>>>>> the order by clause.
>>>>>>>
>>>>>>> Input (dataset json):
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>
>>>>>>> Query:
>>>>>>> for $x in dataset json
>>>>>>> order by $x.b
>>>>>>> return $x
>>>>>>>
>>>>>>> Result:
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>>
>>>>>>> it seems the behavior is comparing by the length of the list not
>>> the
>>>>>> values
>>>>>>> themselves? is it expected?
>>>>>>>
>>>>>>> But if I do something like this:
>>>>>>> for $x in dataset json
>>>>>>> order by $x.b[1]
>>>>>>> return $x
>>>>>>>
>>>>>>> Result:
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> Sorry. The direction of inequality operator was misleading.
>>> STRING
>>>> 13
>>>>>> is
>>>>>>>> smaller than (<) POINT 20.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Taewoo
>>>>>>>>
>>>>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
>> wangsaeu@gmail.com
>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes. Type conversion (casting) only happens among numeric
>> types
>>>> so
>>>>>> far.
>>>>>>>>> Actually, since there is a type-tag, if you try to compare
>> two
>>>> non
>>>>>>>> numeric
>>>>>>>>> types, it stops the comparing as soon as it sees the first
>> byte
>>>>> from
>>>>>>> both
>>>>>>>>> side since type-tag itself has the given order (e.g., STRING
>>> 13 >
>>>>>> POINT
>>>>>>>>> 20). This is required for ORDER BY, too.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Taewoo
>>>>>>>>>
>>>>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>>>> sjaco002@ucr.edu>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I see, so we are technically allowed to compare anything to
>>>>>> anything?
>>>>>>>>>>
>>>>>>>>>> Steven
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>>>> wangsaeu@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> If there is no right comparator for the given types
>> (STRING
>>> vs
>>>>>>> POINT),
>>>>>>>>>> then
>>>>>>>>>>> it does the "byte by byte" comparison.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Taewoo
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
>>>>> sjaco002@ucr.edu
>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This is currently working in master:
>>>>>>>>>>>>
>>>>>>>>>>>> create type CSXType as closed {
>>>>>>>>>>>> id: int32,
>>>>>>>>>>>> csxid: string
>>>>>>>>>>>> }
>>>>>>>>>>>> create dataset CSX(CSXType) primary key id;
>>>>>>>>>>>>
>>>>>>>>>>>> for $b in dataset('CSX')
>>>>>>>>>>>> where $b.id > point("3,5")
>>>>>>>>>>>> return $b;
>>>>>>>>>>>>
>>>>>>>>>>>> Is this supposed to be working?
>>>>>>>>>>>> Steven
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Regards,*
>>>>>>> Wail Alkowaileet
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Ildar
>>>>
>>>
>>
Re: Strange Comparison Allowed
Posted by Mike Carey <dt...@gmail.com>.
Phew! And meanwhile we should incorporate Heri's work to allow meaningful
non-atomic value comparisons and hash joining!
On Aug 19, 2015 3:39 PM, "Taewoo Kim" <wa...@gmail.com> wrote:
> Sorry for my poor memory. Mike is correct. I have checked the codebase.
> Byte-to-byte comparison is should be only conducted for the order by case.
> For equality operations, we do have protection. If you check
> AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
> checks whether the given two values are comparable first. If not, it just
> return false. Therefore, in this case, INT > POINT returns FALSE. The
> result is FALSE, based on the fact that INT and POINT can't be compared,
> not based on the byte-by-byte level comparison.
>
> Best,
> Taewoo
>
> On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
>
> > This all sounds somewhat wrong to me! It's not what I remember from
> design
> > discussions of old... I don't think we should be doing byte by byte
> > comparison between disparate types. Why would users want or expect that?
> > Note that I'm talking about predicate cases - not internal needs like
> order
> > by or routing of data.
> > On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
> >
> > wrote:
> >
> > > @Steven
> > > Index rewrite will not fire in this case, because of type mismatch.
> Hence
> > > it will fallback to non-indexed query results.
> > >
> > > 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
> > >
> > > > @Steven: I never tried. However, it's worthwhile to check. If the
> query
> > > > semantic is correct, the optimizer will try to utilize the index
> > > regardless
> > > > of its type. My guess is, at the end, byte-by-byte comparison will
> > occur.
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
> > > wrote:
> > > >
> > > > > I think this is because the serialized versions of the list have
> > their
> > > > > lengths among the beginning bytes, so this would make sense, since
> we
> > > > don't
> > > > > have a comparator for lists.
> > > > >
> > > > > @Taewoo-What about the case of an index search? Is it okay to pass
> > the
> > > > > wrong type to the search (which will obviously yield unknown
> results)
> > > > >
> > > > > Steven
> > > > >
> > > > > On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
> > wael.y.k@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Actually I observed some strange behavior while comparing
> > > orderedLists
> > > > in
> > > > > > the order by clause.
> > > > > >
> > > > > > Input (dataset json):
> > > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > > >
> > > > > > Query:
> > > > > > for $x in dataset json
> > > > > > order by $x.b
> > > > > > return $x
> > > > > >
> > > > > > Result:
> > > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > > >
> > > > > > it seems the behavior is comparing by the length of the list not
> > the
> > > > > values
> > > > > > themselves? is it expected?
> > > > > >
> > > > > > But if I do something like this:
> > > > > > for $x in dataset json
> > > > > > order by $x.b[1]
> > > > > > return $x
> > > > > >
> > > > > > Result:
> > > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Sorry. The direction of inequality operator was misleading.
> > STRING
> > > 13
> > > > > is
> > > > > > > smaller than (<) POINT 20.
> > > > > > >
> > > > > > > Best,
> > > > > > > Taewoo
> > > > > > >
> > > > > > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
> wangsaeu@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Yes. Type conversion (casting) only happens among numeric
> types
> > > so
> > > > > far.
> > > > > > > > Actually, since there is a type-tag, if you try to compare
> two
> > > non
> > > > > > > numeric
> > > > > > > > types, it stops the comparing as soon as it sees the first
> byte
> > > > from
> > > > > > both
> > > > > > > > side since type-tag itself has the given order (e.g., STRING
> > 13 >
> > > > > POINT
> > > > > > > > 20). This is required for ORDER BY, too.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Taewoo
> > > > > > > >
> > > > > > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
> > > sjaco002@ucr.edu>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> I see, so we are technically allowed to compare anything to
> > > > > anything?
> > > > > > > >>
> > > > > > > >> Steven
> > > > > > > >>
> > > > > > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
> > > wangsaeu@gmail.com>
> > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> > If there is no right comparator for the given types
> (STRING
> > vs
> > > > > > POINT),
> > > > > > > >> then
> > > > > > > >> > it does the "byte by byte" comparison.
> > > > > > > >> >
> > > > > > > >> > Best,
> > > > > > > >> > Taewoo
> > > > > > > >> >
> > > > > > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
> > > > sjaco002@ucr.edu
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > > This is currently working in master:
> > > > > > > >> > >
> > > > > > > >> > > create type CSXType as closed {
> > > > > > > >> > > id: int32,
> > > > > > > >> > > csxid: string
> > > > > > > >> > > }
> > > > > > > >> > > create dataset CSX(CSXType) primary key id;
> > > > > > > >> > >
> > > > > > > >> > > for $b in dataset('CSX')
> > > > > > > >> > > where $b.id > point("3,5")
> > > > > > > >> > > return $b;
> > > > > > > >> > >
> > > > > > > >> > > Is this supposed to be working?
> > > > > > > >> > > Steven
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > *Regards,*
> > > > > > Wail Alkowaileet
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ildar
> > >
> >
>
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
Sorry for my poor memory. Mike is correct. I have checked the codebase.
Byte-to-byte comparison is should be only conducted for the order by case.
For equality operations, we do have protection. If you check
AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
checks whether the given two values are comparable first. If not, it just
return false. Therefore, in this case, INT > POINT returns FALSE. The
result is FALSE, based on the fact that INT and POINT can't be compared,
not based on the byte-by-byte level comparison.
Best,
Taewoo
On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dt...@gmail.com> wrote:
> This all sounds somewhat wrong to me! It's not what I remember from design
> discussions of old... I don't think we should be doing byte by byte
> comparison between disparate types. Why would users want or expect that?
> Note that I'm talking about predicate cases - not internal needs like order
> by or routing of data.
> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <il...@gmail.com>
> wrote:
>
> > @Steven
> > Index rewrite will not fire in this case, because of type mismatch. Hence
> > it will fallback to non-indexed query results.
> >
> > 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
> >
> > > @Steven: I never tried. However, it's worthwhile to check. If the query
> > > semantic is correct, the optimizer will try to utilize the index
> > regardless
> > > of its type. My guess is, at the end, byte-by-byte comparison will
> occur.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
> > wrote:
> > >
> > > > I think this is because the serialized versions of the list have
> their
> > > > lengths among the beginning bytes, so this would make sense, since we
> > > don't
> > > > have a comparator for lists.
> > > >
> > > > @Taewoo-What about the case of an index search? Is it okay to pass
> the
> > > > wrong type to the search (which will obviously yield unknown results)
> > > >
> > > > Steven
> > > >
> > > > On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
> wael.y.k@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Actually I observed some strange behavior while comparing
> > orderedLists
> > > in
> > > > > the order by clause.
> > > > >
> > > > > Input (dataset json):
> > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > >
> > > > > Query:
> > > > > for $x in dataset json
> > > > > order by $x.b
> > > > > return $x
> > > > >
> > > > > Result:
> > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > >
> > > > > it seems the behavior is comparing by the length of the list not
> the
> > > > values
> > > > > themselves? is it expected?
> > > > >
> > > > > But if I do something like this:
> > > > > for $x in dataset json
> > > > > order by $x.b[1]
> > > > > return $x
> > > > >
> > > > > Result:
> > > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Sorry. The direction of inequality operator was misleading.
> STRING
> > 13
> > > > is
> > > > > > smaller than (<) POINT 20.
> > > > > >
> > > > > > Best,
> > > > > > Taewoo
> > > > > >
> > > > > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wangsaeu@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Yes. Type conversion (casting) only happens among numeric types
> > so
> > > > far.
> > > > > > > Actually, since there is a type-tag, if you try to compare two
> > non
> > > > > > numeric
> > > > > > > types, it stops the comparing as soon as it sees the first byte
> > > from
> > > > > both
> > > > > > > side since type-tag itself has the given order (e.g., STRING
> 13 >
> > > > POINT
> > > > > > > 20). This is required for ORDER BY, too.
> > > > > > >
> > > > > > > Best,
> > > > > > > Taewoo
> > > > > > >
> > > > > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
> > sjaco002@ucr.edu>
> > > > > > wrote:
> > > > > > >
> > > > > > >> I see, so we are technically allowed to compare anything to
> > > > anything?
> > > > > > >>
> > > > > > >> Steven
> > > > > > >>
> > > > > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
> > wangsaeu@gmail.com>
> > > > > > wrote:
> > > > > > >>
> > > > > > >> > If there is no right comparator for the given types (STRING
> vs
> > > > > POINT),
> > > > > > >> then
> > > > > > >> > it does the "byte by byte" comparison.
> > > > > > >> >
> > > > > > >> > Best,
> > > > > > >> > Taewoo
> > > > > > >> >
> > > > > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
> > > sjaco002@ucr.edu
> > > > >
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > This is currently working in master:
> > > > > > >> > >
> > > > > > >> > > create type CSXType as closed {
> > > > > > >> > > id: int32,
> > > > > > >> > > csxid: string
> > > > > > >> > > }
> > > > > > >> > > create dataset CSX(CSXType) primary key id;
> > > > > > >> > >
> > > > > > >> > > for $b in dataset('CSX')
> > > > > > >> > > where $b.id > point("3,5")
> > > > > > >> > > return $b;
> > > > > > >> > >
> > > > > > >> > > Is this supposed to be working?
> > > > > > >> > > Steven
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > *Regards,*
> > > > > Wail Alkowaileet
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Ildar
> >
>
Re: Strange Comparison Allowed
Posted by Mike Carey <dt...@gmail.com>.
Also, we should be incorporating Heri's deep equal extensions going forward
in this area!
On Aug 19, 2015 3:09 PM, "Mike Carey" <dt...@gmail.com> wrote:
> This all sounds somewhat wrong to me! It's not what I remember from
> design discussions of old... I don't think we should be doing byte by byte
> comparison between disparate types. Why would users want or expect that?
> Note that I'm talking about predicate cases - not internal needs like order
> by or routing of data.
> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <il...@gmail.com>
> wrote:
>
>> @Steven
>> Index rewrite will not fire in this case, because of type mismatch. Hence
>> it will fallback to non-indexed query results.
>>
>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>>
>> > @Steven: I never tried. However, it's worthwhile to check. If the query
>> > semantic is correct, the optimizer will try to utilize the index
>> regardless
>> > of its type. My guess is, at the end, byte-by-byte comparison will
>> occur.
>> >
>> > Best,
>> > Taewoo
>> >
>> > On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
>> wrote:
>> >
>> > > I think this is because the serialized versions of the list have their
>> > > lengths among the beginning bytes, so this would make sense, since we
>> > don't
>> > > have a comparator for lists.
>> > >
>> > > @Taewoo-What about the case of an index search? Is it okay to pass the
>> > > wrong type to the search (which will obviously yield unknown results)
>> > >
>> > > Steven
>> > >
>> > > On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
>> wael.y.k@gmail.com>
>> > > wrote:
>> > >
>> > > > Actually I observed some strange behavior while comparing
>> orderedLists
>> > in
>> > > > the order by clause.
>> > > >
>> > > > Input (dataset json):
>> > > > { "a": 1i32, "b": [ 1, "hello" ] }
>> > > > { "a": 2i32, "b": [ 1, "hello" ] }
>> > > > { "a": 3i32, "b": [ 1, "hi" ] }
>> > > >
>> > > > Query:
>> > > > for $x in dataset json
>> > > > order by $x.b
>> > > > return $x
>> > > >
>> > > > Result:
>> > > > { "a": 3i32, "b": [ 1, "hi" ] }
>> > > > { "a": 1i32, "b": [ 1, "hello" ] }
>> > > > { "a": 2i32, "b": [ 1, "hello" ] }
>> > > >
>> > > > it seems the behavior is comparing by the length of the list not the
>> > > values
>> > > > themselves? is it expected?
>> > > >
>> > > > But if I do something like this:
>> > > > for $x in dataset json
>> > > > order by $x.b[1]
>> > > > return $x
>> > > >
>> > > > Result:
>> > > > { "a": 1i32, "b": [ 1, "hello" ] }
>> > > > { "a": 2i32, "b": [ 1, "hello" ] }
>> > > > { "a": 3i32, "b": [ 1, "hi" ] }
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
>> > wrote:
>> > > >
>> > > > > Sorry. The direction of inequality operator was misleading.
>> STRING 13
>> > > is
>> > > > > smaller than (<) POINT 20.
>> > > > >
>> > > > > Best,
>> > > > > Taewoo
>> > > > >
>> > > > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
>> > > wrote:
>> > > > >
>> > > > > > Yes. Type conversion (casting) only happens among numeric types
>> so
>> > > far.
>> > > > > > Actually, since there is a type-tag, if you try to compare two
>> non
>> > > > > numeric
>> > > > > > types, it stops the comparing as soon as it sees the first byte
>> > from
>> > > > both
>> > > > > > side since type-tag itself has the given order (e.g., STRING 13
>> >
>> > > POINT
>> > > > > > 20). This is required for ORDER BY, too.
>> > > > > >
>> > > > > > Best,
>> > > > > > Taewoo
>> > > > > >
>> > > > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>> sjaco002@ucr.edu>
>> > > > > wrote:
>> > > > > >
>> > > > > >> I see, so we are technically allowed to compare anything to
>> > > anything?
>> > > > > >>
>> > > > > >> Steven
>> > > > > >>
>> > > > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>> wangsaeu@gmail.com>
>> > > > > wrote:
>> > > > > >>
>> > > > > >> > If there is no right comparator for the given types (STRING
>> vs
>> > > > POINT),
>> > > > > >> then
>> > > > > >> > it does the "byte by byte" comparison.
>> > > > > >> >
>> > > > > >> > Best,
>> > > > > >> > Taewoo
>> > > > > >> >
>> > > > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
>> > sjaco002@ucr.edu
>> > > >
>> > > > > >> wrote:
>> > > > > >> >
>> > > > > >> > > This is currently working in master:
>> > > > > >> > >
>> > > > > >> > > create type CSXType as closed {
>> > > > > >> > > id: int32,
>> > > > > >> > > csxid: string
>> > > > > >> > > }
>> > > > > >> > > create dataset CSX(CSXType) primary key id;
>> > > > > >> > >
>> > > > > >> > > for $b in dataset('CSX')
>> > > > > >> > > where $b.id > point("3,5")
>> > > > > >> > > return $b;
>> > > > > >> > >
>> > > > > >> > > Is this supposed to be working?
>> > > > > >> > > Steven
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > > > *Regards,*
>> > > > Wail Alkowaileet
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> Best regards,
>> Ildar
>>
>
Re: Strange Comparison Allowed
Posted by Mike Carey <dt...@gmail.com>.
This all sounds somewhat wrong to me! It's not what I remember from design
discussions of old... I don't think we should be doing byte by byte
comparison between disparate types. Why would users want or expect that?
Note that I'm talking about predicate cases - not internal needs like order
by or routing of data.
On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <il...@gmail.com>
wrote:
> @Steven
> Index rewrite will not fire in this case, because of type mismatch. Hence
> it will fallback to non-indexed query results.
>
> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
>
> > @Steven: I never tried. However, it's worthwhile to check. If the query
> > semantic is correct, the optimizer will try to utilize the index
> regardless
> > of its type. My guess is, at the end, byte-by-byte comparison will occur.
> >
> > Best,
> > Taewoo
> >
> > On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu>
> wrote:
> >
> > > I think this is because the serialized versions of the list have their
> > > lengths among the beginning bytes, so this would make sense, since we
> > don't
> > > have a comparator for lists.
> > >
> > > @Taewoo-What about the case of an index search? Is it okay to pass the
> > > wrong type to the search (which will obviously yield unknown results)
> > >
> > > Steven
> > >
> > > On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <wael.y.k@gmail.com
> >
> > > wrote:
> > >
> > > > Actually I observed some strange behavior while comparing
> orderedLists
> > in
> > > > the order by clause.
> > > >
> > > > Input (dataset json):
> > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > >
> > > > Query:
> > > > for $x in dataset json
> > > > order by $x.b
> > > > return $x
> > > >
> > > > Result:
> > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > >
> > > > it seems the behavior is comparing by the length of the list not the
> > > values
> > > > themselves? is it expected?
> > > >
> > > > But if I do something like this:
> > > > for $x in dataset json
> > > > order by $x.b[1]
> > > > return $x
> > > >
> > > > Result:
> > > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > >
> > > >
> > > >
> > > > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
> > wrote:
> > > >
> > > > > Sorry. The direction of inequality operator was misleading. STRING
> 13
> > > is
> > > > > smaller than (<) POINT 20.
> > > > >
> > > > > Best,
> > > > > Taewoo
> > > > >
> > > > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Yes. Type conversion (casting) only happens among numeric types
> so
> > > far.
> > > > > > Actually, since there is a type-tag, if you try to compare two
> non
> > > > > numeric
> > > > > > types, it stops the comparing as soon as it sees the first byte
> > from
> > > > both
> > > > > > side since type-tag itself has the given order (e.g., STRING 13 >
> > > POINT
> > > > > > 20). This is required for ORDER BY, too.
> > > > > >
> > > > > > Best,
> > > > > > Taewoo
> > > > > >
> > > > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
> sjaco002@ucr.edu>
> > > > > wrote:
> > > > > >
> > > > > >> I see, so we are technically allowed to compare anything to
> > > anything?
> > > > > >>
> > > > > >> Steven
> > > > > >>
> > > > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
> wangsaeu@gmail.com>
> > > > > wrote:
> > > > > >>
> > > > > >> > If there is no right comparator for the given types (STRING vs
> > > > POINT),
> > > > > >> then
> > > > > >> > it does the "byte by byte" comparison.
> > > > > >> >
> > > > > >> > Best,
> > > > > >> > Taewoo
> > > > > >> >
> > > > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
> > sjaco002@ucr.edu
> > > >
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > > This is currently working in master:
> > > > > >> > >
> > > > > >> > > create type CSXType as closed {
> > > > > >> > > id: int32,
> > > > > >> > > csxid: string
> > > > > >> > > }
> > > > > >> > > create dataset CSX(CSXType) primary key id;
> > > > > >> > >
> > > > > >> > > for $b in dataset('CSX')
> > > > > >> > > where $b.id > point("3,5")
> > > > > >> > > return $b;
> > > > > >> > >
> > > > > >> > > Is this supposed to be working?
> > > > > >> > > Steven
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Regards,*
> > > > Wail Alkowaileet
> > > >
> > >
> >
>
>
>
> --
> Best regards,
> Ildar
>
Re: Strange Comparison Allowed
Posted by Ildar Absalyamov <il...@gmail.com>.
@Steven
Index rewrite will not fire in this case, because of type mismatch. Hence
it will fallback to non-indexed query results.
2015-08-19 11:25 GMT-07:00 Taewoo Kim <wa...@gmail.com>:
> @Steven: I never tried. However, it's worthwhile to check. If the query
> semantic is correct, the optimizer will try to utilize the index regardless
> of its type. My guess is, at the end, byte-by-byte comparison will occur.
>
> Best,
> Taewoo
>
> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu> wrote:
>
> > I think this is because the serialized versions of the list have their
> > lengths among the beginning bytes, so this would make sense, since we
> don't
> > have a comparator for lists.
> >
> > @Taewoo-What about the case of an index search? Is it okay to pass the
> > wrong type to the search (which will obviously yield unknown results)
> >
> > Steven
> >
> > On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <wa...@gmail.com>
> > wrote:
> >
> > > Actually I observed some strange behavior while comparing orderedLists
> in
> > > the order by clause.
> > >
> > > Input (dataset json):
> > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > { "a": 3i32, "b": [ 1, "hi" ] }
> > >
> > > Query:
> > > for $x in dataset json
> > > order by $x.b
> > > return $x
> > >
> > > Result:
> > > { "a": 3i32, "b": [ 1, "hi" ] }
> > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > { "a": 2i32, "b": [ 1, "hello" ] }
> > >
> > > it seems the behavior is comparing by the length of the list not the
> > values
> > > themselves? is it expected?
> > >
> > > But if I do something like this:
> > > for $x in dataset json
> > > order by $x.b[1]
> > > return $x
> > >
> > > Result:
> > > { "a": 1i32, "b": [ 1, "hello" ] }
> > > { "a": 2i32, "b": [ 1, "hello" ] }
> > > { "a": 3i32, "b": [ 1, "hi" ] }
> > >
> > >
> > >
> > > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com>
> wrote:
> > >
> > > > Sorry. The direction of inequality operator was misleading. STRING 13
> > is
> > > > smaller than (<) POINT 20.
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
> > wrote:
> > > >
> > > > > Yes. Type conversion (casting) only happens among numeric types so
> > far.
> > > > > Actually, since there is a type-tag, if you try to compare two non
> > > > numeric
> > > > > types, it stops the comparing as soon as it sees the first byte
> from
> > > both
> > > > > side since type-tag itself has the given order (e.g., STRING 13 >
> > POINT
> > > > > 20). This is required for ORDER BY, too.
> > > > >
> > > > > Best,
> > > > > Taewoo
> > > > >
> > > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu>
> > > > wrote:
> > > > >
> > > > >> I see, so we are technically allowed to compare anything to
> > anything?
> > > > >>
> > > > >> Steven
> > > > >>
> > > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> > If there is no right comparator for the given types (STRING vs
> > > POINT),
> > > > >> then
> > > > >> > it does the "byte by byte" comparison.
> > > > >> >
> > > > >> > Best,
> > > > >> > Taewoo
> > > > >> >
> > > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <
> sjaco002@ucr.edu
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> > > This is currently working in master:
> > > > >> > >
> > > > >> > > create type CSXType as closed {
> > > > >> > > id: int32,
> > > > >> > > csxid: string
> > > > >> > > }
> > > > >> > > create dataset CSX(CSXType) primary key id;
> > > > >> > >
> > > > >> > > for $b in dataset('CSX')
> > > > >> > > where $b.id > point("3,5")
> > > > >> > > return $b;
> > > > >> > >
> > > > >> > > Is this supposed to be working?
> > > > >> > > Steven
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Regards,*
> > > Wail Alkowaileet
> > >
> >
>
--
Best regards,
Ildar
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
@Steven: I never tried. However, it's worthwhile to check. If the query
semantic is correct, the optimizer will try to utilize the index regardless
of its type. My guess is, at the end, byte-by-byte comparison will occur.
Best,
Taewoo
On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sj...@ucr.edu> wrote:
> I think this is because the serialized versions of the list have their
> lengths among the beginning bytes, so this would make sense, since we don't
> have a comparator for lists.
>
> @Taewoo-What about the case of an index search? Is it okay to pass the
> wrong type to the search (which will obviously yield unknown results)
>
> Steven
>
> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <wa...@gmail.com>
> wrote:
>
> > Actually I observed some strange behavior while comparing orderedLists in
> > the order by clause.
> >
> > Input (dataset json):
> > { "a": 1i32, "b": [ 1, "hello" ] }
> > { "a": 2i32, "b": [ 1, "hello" ] }
> > { "a": 3i32, "b": [ 1, "hi" ] }
> >
> > Query:
> > for $x in dataset json
> > order by $x.b
> > return $x
> >
> > Result:
> > { "a": 3i32, "b": [ 1, "hi" ] }
> > { "a": 1i32, "b": [ 1, "hello" ] }
> > { "a": 2i32, "b": [ 1, "hello" ] }
> >
> > it seems the behavior is comparing by the length of the list not the
> values
> > themselves? is it expected?
> >
> > But if I do something like this:
> > for $x in dataset json
> > order by $x.b[1]
> > return $x
> >
> > Result:
> > { "a": 1i32, "b": [ 1, "hello" ] }
> > { "a": 2i32, "b": [ 1, "hello" ] }
> > { "a": 3i32, "b": [ 1, "hi" ] }
> >
> >
> >
> > On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com> wrote:
> >
> > > Sorry. The direction of inequality operator was misleading. STRING 13
> is
> > > smaller than (<) POINT 20.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com>
> wrote:
> > >
> > > > Yes. Type conversion (casting) only happens among numeric types so
> far.
> > > > Actually, since there is a type-tag, if you try to compare two non
> > > numeric
> > > > types, it stops the comparing as soon as it sees the first byte from
> > both
> > > > side since type-tag itself has the given order (e.g., STRING 13 >
> POINT
> > > > 20). This is required for ORDER BY, too.
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu>
> > > wrote:
> > > >
> > > >> I see, so we are technically allowed to compare anything to
> anything?
> > > >>
> > > >> Steven
> > > >>
> > > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com>
> > > wrote:
> > > >>
> > > >> > If there is no right comparator for the given types (STRING vs
> > POINT),
> > > >> then
> > > >> > it does the "byte by byte" comparison.
> > > >> >
> > > >> > Best,
> > > >> > Taewoo
> > > >> >
> > > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sjaco002@ucr.edu
> >
> > > >> wrote:
> > > >> >
> > > >> > > This is currently working in master:
> > > >> > >
> > > >> > > create type CSXType as closed {
> > > >> > > id: int32,
> > > >> > > csxid: string
> > > >> > > }
> > > >> > > create dataset CSX(CSXType) primary key id;
> > > >> > >
> > > >> > > for $b in dataset('CSX')
> > > >> > > where $b.id > point("3,5")
> > > >> > > return $b;
> > > >> > >
> > > >> > > Is this supposed to be working?
> > > >> > > Steven
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Regards,*
> > Wail Alkowaileet
> >
>
Re: Strange Comparison Allowed
Posted by Steven Jacobs <sj...@ucr.edu>.
I think this is because the serialized versions of the list have their
lengths among the beginning bytes, so this would make sense, since we don't
have a comparator for lists.
@Taewoo-What about the case of an index search? Is it okay to pass the
wrong type to the search (which will obviously yield unknown results)
Steven
On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <wa...@gmail.com>
wrote:
> Actually I observed some strange behavior while comparing orderedLists in
> the order by clause.
>
> Input (dataset json):
> { "a": 1i32, "b": [ 1, "hello" ] }
> { "a": 2i32, "b": [ 1, "hello" ] }
> { "a": 3i32, "b": [ 1, "hi" ] }
>
> Query:
> for $x in dataset json
> order by $x.b
> return $x
>
> Result:
> { "a": 3i32, "b": [ 1, "hi" ] }
> { "a": 1i32, "b": [ 1, "hello" ] }
> { "a": 2i32, "b": [ 1, "hello" ] }
>
> it seems the behavior is comparing by the length of the list not the values
> themselves? is it expected?
>
> But if I do something like this:
> for $x in dataset json
> order by $x.b[1]
> return $x
>
> Result:
> { "a": 1i32, "b": [ 1, "hello" ] }
> { "a": 2i32, "b": [ 1, "hello" ] }
> { "a": 3i32, "b": [ 1, "hi" ] }
>
>
>
> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com> wrote:
>
> > Sorry. The direction of inequality operator was misleading. STRING 13 is
> > smaller than (<) POINT 20.
> >
> > Best,
> > Taewoo
> >
> > On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com> wrote:
> >
> > > Yes. Type conversion (casting) only happens among numeric types so far.
> > > Actually, since there is a type-tag, if you try to compare two non
> > numeric
> > > types, it stops the comparing as soon as it sees the first byte from
> both
> > > side since type-tag itself has the given order (e.g., STRING 13 > POINT
> > > 20). This is required for ORDER BY, too.
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu>
> > wrote:
> > >
> > >> I see, so we are technically allowed to compare anything to anything?
> > >>
> > >> Steven
> > >>
> > >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com>
> > wrote:
> > >>
> > >> > If there is no right comparator for the given types (STRING vs
> POINT),
> > >> then
> > >> > it does the "byte by byte" comparison.
> > >> >
> > >> > Best,
> > >> > Taewoo
> > >> >
> > >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu>
> > >> wrote:
> > >> >
> > >> > > This is currently working in master:
> > >> > >
> > >> > > create type CSXType as closed {
> > >> > > id: int32,
> > >> > > csxid: string
> > >> > > }
> > >> > > create dataset CSX(CSXType) primary key id;
> > >> > >
> > >> > > for $b in dataset('CSX')
> > >> > > where $b.id > point("3,5")
> > >> > > return $b;
> > >> > >
> > >> > > Is this supposed to be working?
> > >> > > Steven
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
>
>
> --
>
> *Regards,*
> Wail Alkowaileet
>
Re: Strange Comparison Allowed
Posted by Wail Alkowaileet <wa...@gmail.com>.
Actually I observed some strange behavior while comparing orderedLists in
the order by clause.
Input (dataset json):
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
{ "a": 3i32, "b": [ 1, "hi" ] }
Query:
for $x in dataset json
order by $x.b
return $x
Result:
{ "a": 3i32, "b": [ 1, "hi" ] }
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
it seems the behavior is comparing by the length of the list not the values
themselves? is it expected?
But if I do something like this:
for $x in dataset json
order by $x.b[1]
return $x
Result:
{ "a": 1i32, "b": [ 1, "hello" ] }
{ "a": 2i32, "b": [ 1, "hello" ] }
{ "a": 3i32, "b": [ 1, "hi" ] }
On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wa...@gmail.com> wrote:
> Sorry. The direction of inequality operator was misleading. STRING 13 is
> smaller than (<) POINT 20.
>
> Best,
> Taewoo
>
> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com> wrote:
>
> > Yes. Type conversion (casting) only happens among numeric types so far.
> > Actually, since there is a type-tag, if you try to compare two non
> numeric
> > types, it stops the comparing as soon as it sees the first byte from both
> > side since type-tag itself has the given order (e.g., STRING 13 > POINT
> > 20). This is required for ORDER BY, too.
> >
> > Best,
> > Taewoo
> >
> > On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu>
> wrote:
> >
> >> I see, so we are technically allowed to compare anything to anything?
> >>
> >> Steven
> >>
> >> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com>
> wrote:
> >>
> >> > If there is no right comparator for the given types (STRING vs POINT),
> >> then
> >> > it does the "byte by byte" comparison.
> >> >
> >> > Best,
> >> > Taewoo
> >> >
> >> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu>
> >> wrote:
> >> >
> >> > > This is currently working in master:
> >> > >
> >> > > create type CSXType as closed {
> >> > > id: int32,
> >> > > csxid: string
> >> > > }
> >> > > create dataset CSX(CSXType) primary key id;
> >> > >
> >> > > for $b in dataset('CSX')
> >> > > where $b.id > point("3,5")
> >> > > return $b;
> >> > >
> >> > > Is this supposed to be working?
> >> > > Steven
> >> > >
> >> >
> >>
> >
> >
>
--
*Regards,*
Wail Alkowaileet
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
Sorry. The direction of inequality operator was misleading. STRING 13 is
smaller than (<) POINT 20.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <wa...@gmail.com> wrote:
> Yes. Type conversion (casting) only happens among numeric types so far.
> Actually, since there is a type-tag, if you try to compare two non numeric
> types, it stops the comparing as soon as it sees the first byte from both
> side since type-tag itself has the given order (e.g., STRING 13 > POINT
> 20). This is required for ORDER BY, too.
>
> Best,
> Taewoo
>
> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu> wrote:
>
>> I see, so we are technically allowed to compare anything to anything?
>>
>> Steven
>>
>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com> wrote:
>>
>> > If there is no right comparator for the given types (STRING vs POINT),
>> then
>> > it does the "byte by byte" comparison.
>> >
>> > Best,
>> > Taewoo
>> >
>> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu>
>> wrote:
>> >
>> > > This is currently working in master:
>> > >
>> > > create type CSXType as closed {
>> > > id: int32,
>> > > csxid: string
>> > > }
>> > > create dataset CSX(CSXType) primary key id;
>> > >
>> > > for $b in dataset('CSX')
>> > > where $b.id > point("3,5")
>> > > return $b;
>> > >
>> > > Is this supposed to be working?
>> > > Steven
>> > >
>> >
>>
>
>
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
Yes. Type conversion (casting) only happens among numeric types so far.
Actually, since there is a type-tag, if you try to compare two non numeric
types, it stops the comparing as soon as it sees the first byte from both
side since type-tag itself has the given order (e.g., STRING 13 > POINT
20). This is required for ORDER BY, too.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <sj...@ucr.edu> wrote:
> I see, so we are technically allowed to compare anything to anything?
>
> Steven
>
> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com> wrote:
>
> > If there is no right comparator for the given types (STRING vs POINT),
> then
> > it does the "byte by byte" comparison.
> >
> > Best,
> > Taewoo
> >
> > On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu>
> wrote:
> >
> > > This is currently working in master:
> > >
> > > create type CSXType as closed {
> > > id: int32,
> > > csxid: string
> > > }
> > > create dataset CSX(CSXType) primary key id;
> > >
> > > for $b in dataset('CSX')
> > > where $b.id > point("3,5")
> > > return $b;
> > >
> > > Is this supposed to be working?
> > > Steven
> > >
> >
>
Re: Strange Comparison Allowed
Posted by Steven Jacobs <sj...@ucr.edu>.
I see, so we are technically allowed to compare anything to anything?
Steven
On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <wa...@gmail.com> wrote:
> If there is no right comparator for the given types (STRING vs POINT), then
> it does the "byte by byte" comparison.
>
> Best,
> Taewoo
>
> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu> wrote:
>
> > This is currently working in master:
> >
> > create type CSXType as closed {
> > id: int32,
> > csxid: string
> > }
> > create dataset CSX(CSXType) primary key id;
> >
> > for $b in dataset('CSX')
> > where $b.id > point("3,5")
> > return $b;
> >
> > Is this supposed to be working?
> > Steven
> >
>
Re: Strange Comparison Allowed
Posted by Taewoo Kim <wa...@gmail.com>.
If there is no right comparator for the given types (STRING vs POINT), then
it does the "byte by byte" comparison.
Best,
Taewoo
On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs <sj...@ucr.edu> wrote:
> This is currently working in master:
>
> create type CSXType as closed {
> id: int32,
> csxid: string
> }
> create dataset CSX(CSXType) primary key id;
>
> for $b in dataset('CSX')
> where $b.id > point("3,5")
> return $b;
>
> Is this supposed to be working?
> Steven
>