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 <wangs...@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....@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 <wangs...@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 <heri...@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 <dtab...@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....@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
