asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <wangs...@gmail.com>
Subject Re: Strange Comparison Allowed
Date Wed, 19 Aug 2015 18:25:59 GMT
@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 <sjaco002@ucr.edu> 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 <wael.y.k@gmail.com>
> 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 <wangsaeu@gmail.com> 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 <wangsaeu@gmail.com>
> 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 <sjaco002@ucr.edu>
> > > 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 <wangsaeu@gmail.com>
> > > 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 <sjaco002@ucr.edu
> >
> > > >> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message