Got it... On Fri, Dec 29, 2017 at 10:01 PM, Mike Carey <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > > > > 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 <[email protected]> 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 < > > > [email protected] > > > > > > > > > > >> 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
