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