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 > > > > > >
