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 <[email protected]> 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" <[email protected]> > 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 <[email protected]>: >> >>> @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 <[email protected]> >> 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 <[email protected] >>> >>>> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 < >> [email protected]> >>>>>> 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 < >> [email protected]> >>>>>> 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 < >>> [email protected] >>>>> >>>>>>>> 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 >>
