asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Strange Comparison Allowed
Date Wed, 19 Aug 2015 22:44:54 GMT
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" <wangsaeu@gmail.com> 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 <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