Poor group by compilation error message

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the attached query using the attached data file.
2. Make sure to modify the data file path to the attached file.

What is the expected output? What do you see instead?
Item should be grouped by Ids; however, I'm getting the following exception 
during compilation:
edu.uci.ics.hyracks.algebricks.core.api.exceptions.AlgebricksException: 
Unsupported type [ closed {
  id: INT32,
  loc: POINT
}
 ] for field access expression: function-call: asterix:field-access-by-name, Args:[%0->$$5, AString: {id}]
    at edu.uci.ics.asterix.om.typecomputer.impl.NonTaggedFieldAccessByNameResultType.getRecordTypeFromType(NonTaggedFieldAccessByNameResultType.java:73)
    at edu.uci.ics.asterix.om.typecomputer.impl.NonTaggedFieldAccessByNameResultType.computeType(NonTaggedFieldAccessByNameResultType.java:38)
    at edu.uci.ics.asterix.dataflow.data.common.AqlExpressionTypeComputer.getTypeForFunction(AqlExpressionTypeComputer.java:67)
    at edu.uci.ics.asterix.dataflow.data.common.AqlExpressionTypeComputer.getType(AqlExpressionTypeComputer.java:41)
    at edu.uci.ics.hyracks.algebricks.core.algebra.operators.logical.AssignOperator.computeOutputTypeEnvironment(AssignOperator.java:86)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.AlgebricksOptimizationContext.computeAndSetTypeEnvironmentForOperator(AlgebricksOptimizationContext.java:257)
    at edu.uci.ics.hyracks.algebricks.rewriter.rules.InferTypesRule.rewritePost(InferTypesRule.java:24)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.AbstractRuleController.rewriteOperatorRef(AbstractRuleController.java:108)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.AbstractRuleController.rewriteOperatorRef(AbstractRuleController.java:83)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.AbstractRuleController.rewriteOperatorRef(AbstractRuleController.java:83)
    at edu.uci.ics.hyracks.algebricks.compiler.rewriter.rulecontrollers.SequentialOnceRuleController.rewriteWithRuleCollection(SequentialOnceRuleController.java:40)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.HeuristicOptimizer.runOptimizationSets(HeuristicOptimizer.java:79)
    at edu.uci.ics.hyracks.algebricks.core.rewriter.base.HeuristicOptimizer.optimize(HeuristicOptimizer.java:66)
    at edu.uci.ics.hyracks.algebricks.compiler.api.HeuristicCompilerFactoryBuilder$1$1.optimize(HeuristicCompilerFactoryBuilder.java:80)
    at edu.uci.ics.asterix.api.common.APIFramework.compileQueryInternal(APIFramework.java:470)
    at edu.uci.ics.asterix.api.common.APIFramework.compileQuery(APIFramework.java:307)
    at edu.uci.ics.asterix.api.java.AsterixJavaClient.compile(AsterixJavaClient.java:79)
    at edu.uci.ics.asterix.test.aql.TestsUtils.runScriptAndCompareWithResult(TestsUtils.java:54)
    at edu.uci.ics.asterix.test.runtime.RuntimeTest.test(RuntimeTest.java:154)
    at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.junit.runners.Suite.runChild(Suite.java:128)
    at org.junit.runners.Suite.runChild(Suite.java:24)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Original issue reported on code.google.com by salsuba...@gmail.com on 14 Mar 2012 at 1:58

Attachments:

• query.aql
• dataFile.json

[GoogleCodeExporter]

Yingyi,

Can you verify this issue and report the cause/fix?

Original comment by vinay...@gmail.com on 6 Apr 2012 at 8:49

• Added labels: P1

[GoogleCodeExporter]

I believe there is a bug in the query. Our group-by is just too confusing :/

Before query:

for $o in dataset('MyData')
group by $o.id with $o
return $o.id

Notice that $o has been re-bound to the collection containing a group, and 
hence the field access $o.id doesn't make sense because the field access 
function does not work on collections (which is exactly what the error message 
states).

A possible fix for this query is this:

for $o in dataset('MyData')
group by $id := $o.id with $o
return $id

Can we close this issue?

Original comment by alexande...@gmail.com on 2 Aug 2012 at 4:12

[GoogleCodeExporter]

I would take issue with "which is exactly what the error message states".
I would however (slightly grudgingly) agree with "which is exactly what the 
error message really means". :-)
SERIOUSLY!
This error message, for an AQL user, will be next to impenetrable, despite its 
internals-oriented technical correctness.  We need something more like:
"Incorrect field access "$o.id" in return clause applied to variable $o bound 
in with clause of group clause."  (Preferable with positional information, 
e.g., line and character position, to better pinpoint things.)
We also need an option to turn off stack tracing for end users (including 
Khurram) so that ASTERIX users don't get those - and a way to turn them on in 
the query header when things go wrong and one wants to file issues on them.
Our end users should not have to dig through the traces (and they should not be 
part of the expected results) to see the crux of the errors - and they are too 
much "Java noise".
TRANSLATION:  ASTERIX errors should be given in ASTERIX user lingo.

Original comment by dtab...@gmail.com on 2 Aug 2012 at 2:21

• Changed title: Poor group by compilation error message

[GoogleCodeExporter]

Alright. This is a bigger fix then, because *all* our error messages are 
internals-oriented.

Original comment by alexande...@gmail.com on 2 Aug 2012 at 8:37

[GoogleCodeExporter]

Yingyi/Alex/Sattam - What is the status of this issue ?

Original comment by khfaraaz82 on 19 Nov 2012 at 3:55

[GoogleCodeExporter]

After the above discussion I don't know what it means to fix this issue 
properly.
Constructing the error message that Mike wants is very, very difficult. If that 
is the expected solution, then I don't know when we can implement it.

Original comment by alexande...@gmail.com on 19 Nov 2012 at 9:36

[GoogleCodeExporter]

Here is a compromise:

Change the error message returned by the asterix:field-access-by-name when 
trying to access a field in a non-record (a list in this case), to say 
something like:

Field Accessor for `id' cannot be applied to a <non-record type>. Type of 
input: <pretty printed input type>

Replace the <..> with concrete values while generating the error message.

Original comment by vinay...@gmail.com on 19 Nov 2012 at 9:47

[GoogleCodeExporter]

Sounds good to me.

Original comment by alexande...@gmail.com on 19 Nov 2012 at 9:56

[GoogleCodeExporter]

Original comment by vinay...@gmail.com on 10 May 2013 at 7:05

• Added labels: Severity-BetaBlocker
• Removed labels: P1

[GoogleCodeExporter]

Vinayak - my understanding is that you are putting in place the generic more 
end-user-friendly exception reporting soon - what's your ETA for that - and 
when you have that done could you please update THIS issue with the new 
still-internally-oriented error message?  This will be an interesting test case 
for that.  thx!

Original comment by dtab...@gmail.com on 14 May 2013 at 11:13

[GoogleCodeExporter]

Original comment by vinay...@gmail.com on 17 May 2013 at 7:36

[GoogleCodeExporter]

Add documentation for grouping to reduce probability for user errors.

Original comment by westm...@gmail.com on 17 May 2013 at 7:38

[GoogleCodeExporter]

Original comment by westm...@gmail.com on 17 May 2013 at 7:46

• Added labels: Type-Documentation
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by westm...@gmail.com on 28 May 2013 at 5:51

• Changed state: Started

[GoogleCodeExporter]

The documentation for grouping is in.

Changing the error message as proposed by Vinayak in comment #7 is not a 
BetaBlocker.

Original comment by westm...@gmail.com on 4 Jun 2013 at 9:03

• Removed labels: Severity-BetaBlocker