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