Group by comparison of complex values

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start up the Asterix Web UI (from 0.8.7 snapshot, latest version of master).
2. Type the following query :

let $x := {{
    { "id" : 1, "age" :  12 },
   { "age" : 12, "id" : 1}
}}
for $person in $x
group by $person := $person with $x
return {
  "person" : $person
};

What is the expected output? What do you see instead?

Expected : 

{ "id": 1, "age": 12 }

Actual : 

{ "id": 1, "age": 12 }
{ "age": 12, "id": 1 }

Unless I am mistaken, the order in which attribute names appear in a record 
shouldn't matter
I cannot implement the distinct into group-by if the group by doesn't do what I 
expect :(.

This issue is probably related to issue #844.

Original issue reported on code.google.com by jules.te...@gmail.com on 24 Feb 2015 at 9:00

• Blocking: #854

[GoogleCodeExporter]

Original comment by jules.te...@gmail.com on 24 Feb 2015 at 9:00

• Now blocking: #854

[GoogleCodeExporter]

Actually, this result is consistent with the statement that AQL does not 
support comparison of complex values. Maybe this was the reason to have a 
distinct operator separate from the group by in the first place?

Original comment by jules.te...@gmail.com on 25 Feb 2015 at 12:59

[GoogleCodeExporter]

Jules, your last comment is right in terms of only supporting scalar compares - 
which means the bug is that the query doesn't get a runtime type error.  This 
makes me wonder if we have some remaining holes that didn't get plugged when 
Taewoo was doing his heroic work on getting comparisons right everywhere. (In 
addition to making sure the right scalar comparisons are made, we need to 
error-out if the result is not scalar.)

Original comment by dtab...@gmail.com on 25 Feb 2015 at 7:21

[GoogleCodeExporter]

PS - On the grouping vs. distinct-ing front, we have both simply for usability 
reasons.  (Under the covers we should rewrite, as you know, distinct-ing into 
grouping without formation of the groups' associated info.)

Original comment by dtab...@gmail.com on 25 Feb 2015 at 7:22

[GoogleCodeExporter]

Actually, right now, in my INT64 + Type Casting branch, as well as in master 
branch, if two types are not comparable, we are just doing the byte-by-byte 
comparison. Unordered list or record is this case. Thus, we do not want to 
compare complex values such as unordered list, ordered list, and records?

Original comment by wangs...@gmail.com on 25 Feb 2015 at 7:36