asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wail Alkowaileet <wael....@gmail.com>
Subject Re: Comparison semantics for complex types
Date Sat, 30 Dec 2017 21:08:43 GMT
Got it...

On Fri, Dec 29, 2017 at 10:01 PM, Mike Carey <dtabass@gmail.com> wrote:

> This is strictly a language question whose answer should have nothing to do
> with implementation issues.  The = operator is valid - it's not an error if
> its arguments are complex.
>
>
>
> On Dec 29, 2017 9:20 PM, "Wail Alkowaileet" <wael.y.k@gmail.com> wrote:
>
> What I meant is that the user should explicitly call deep_equal. So we
> should not implicitly call it if we found out we're comparing two complex
> types. Therefore, I think we should throw an exception when an expression x
> = y found and x and y are complex types. (probably guide the user to use
> deep_equal instead).
> The reason is when the compiler generates the plan for join using deep
> equal, it picks nested loop join instead of hash join.
> But If the type is known at runtime (open type) and we can implicitly call
> deep_equal then we're not sure what join algorithm we should pick as x and
> y can be of any type.
>
> We need to compute the hash for the hash join to resolve hash(x) and
> hash(y) equally. And I was thinking that it's a bit complex to have a hash
> function for complex types (what would be the hash code for a multiset of
> objects?)
>
> Sorry for my bad explanation :-)
>
>
> On Fri, Dec 29, 2017 at 8:47 PM, Taewoo Kim <wangsaeu@gmail.com> wrote:
>
> > I have two questions. How would you want to compare two complex objects?
> > And why do we need to do a hash?
> >
> > On Fri, Dec 29, 2017 at 20:31 Wail Alkowaileet <wael.y.k@gmail.com>
> wrote:
> >
> > > I think we should not call deep_equal implicitly when comparing
> objects,
> > > arrays or multisets.
> > > One reason is that we don't want to do hash join where the key is a
> > complex
> > > type (i.e what would be the hash function?).
> > >
> > > On Fri, Dec 29, 2017 at 10:24 AM, Taewoo Kim <wangsaeu@gmail.com>
> wrote:
> > >
> > > > @Heri: I'm sorry for not mentioning your deep_equal function. Yeah,
> > > indeed,
> > > > we have your function. I checked BuiltinFunctions and found the
> > function
> > > > named "deep-equal". So, we need to explicitly use that function to
> > > conduct
> > > > such comparison? If so, could you revise Wail's query? And it would
> be
> > > nice
> > > > if AsterixDB can call that function when it tries to compare arrays.
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Fri, Dec 29, 2017 at 8:59 AM, Heri Ramampiaro <heriram@gmail.com>
> > > > wrote:
> > > >
> > > > > Is this similar to the “deep_equal” function I implemented a
while
> > ago?
> > > > >
> > > > > -heri
> > > > >
> > > > > Sent from my iPhone
> > > > >
> > > > > > On Dec 29, 2017, at 17:23, Mike Carey <dtabass@gmail.com>
wrote:
> > > > > >
> > > > > > Indeed - we need it someday!  (Sooner rather than later would
be
> > > nice.)
> > > > > It basically needs to work like it does in languages like Python,
I
> > > > think.
> > > > > (Cardinality and element by element equality for arrays,
> cardinality
> > > and
> > > > > order-independent equality for bags, field by field equality for
> > > records,
> > > > > and recursively through all of them.)
> > > > > >
> > > > > >
> > > > > >> On 12/28/17 11:14 PM, Taewoo Kim wrote:
> > > > > >> If I remember correctly, we don't support deep equality
> comparison
> > > in
> > > > > >> AsterixDB yet.
> > > > > >>
> > > > > >> Best,
> > > > > >> Taewoo
> > > > > >>
> > > > > >> On Thu, Dec 28, 2017 at 9:19 PM, Wail Alkowaileet <
> > > wael.y.k@gmail.com
> > > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Hi Devs,
> > > > > >>>
> > > > > >>> Currently we have an inconsistent behavior regarding
the
> > > comparators:
> > > > > >>>
> > > > > >>> In join, we allow such operation
> > > > > >>>
> > > > > >>> SELECT *
> > > > > >>> FROM [[1],[2],[3]] array1, [[1],[2],[3]] array2
> > > > > >>> WHERE array1 = array2
> > > > > >>>
> > > > > >>> In select, an exception is thrown
> > > > > >>> SELECT *
> > > > > >>> FROM [[1],[2],[3]] array1
> > > > > >>> WHERE array1 = [1]
> > > > > >>>
> > > > > >>> Error ASX0004: Unsupported type: comparison operations
(>, >=,
> <,
> > > and
> > > > > <=)
> > > > > >>> cannot process input type array
> > > > > >>>
> > > > > >>> What should be the semantics for such operations?
> > > > > >>>
> > > > > >>>
> > > > > >>> --
> > > > > >>>
> > > > > >>> *Regards,*
> > > > > >>> Wail Alkowaileet
> > > > > >>>
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Regards,*
> > > Wail Alkowaileet
> > >
> >
>
>
>
> --
>
> *Regards,*
> Wail Alkowaileet
>



-- 

*Regards,*
Wail Alkowaileet

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