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 22:29:58 GMT
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 <dtabass@gmail.com> 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" <ildar.absalyamov@gmail.com>
> 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 <wangsaeu@gmail.com>:
> >
> > > @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
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Ildar
> >
>

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