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