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