Use of a variable holding result of a range expression causes ClassCastException

[GoogleCodeExporter]

What steps will reproduce the problem?

Input statements:

let $x:=range(1,100)
for $i in $x
return $i

Logical plan:

write [%0->$$1] -- |UNPARTITIONED|
  project ([$$1]) -- |UNPARTITIONED|
    unnest $$1 <- function-call: asterix:scan-collection, Args:[%0->$$0] -- |UNPARTITIONED|
      assign [$$0] <- [function-call: asterix:range, Args:[AInt32: {1}, AInt32: {100}]] -- |UNPARTITIONED|
        empty-tuple-source -- |UNPARTITIONED|

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

java.lang.ClassCastException: edu.uci.ics.asterix.om.types.BuiltinType$4 cannot 
be cast to edu.uci.ics.asterix.om.types.AbstractCollectionType

Please use labels and text to provide additional information.
asterix_stabilization: rev 719

Original issue reported on code.google.com by RamanGro...@gmail.com on 15 Sep 2012 at 8:18

[GoogleCodeExporter]

Original comment by khfaraaz82 on 17 Sep 2012 at 7:57

[GoogleCodeExporter]

Original comment by khfaraaz82 on 16 Oct 2012 at 6:04

• Added labels: P1

[GoogleCodeExporter]

This is not bug, because "range" is defined as an unnesting function instead of 
collection-constructor function. An unnesting function returns a series of 
values one-by-one instead of a single value. Therefore you cannot say:

let $x:=range(1,100)

Instead, you can write that query as:
for $i in range(1,100)
return $i

The same thing applied to function "dataset". You can not say:
let $x:=dataset("X")

but you can say:
for $i in dateset("x")
return $x

Original comment by buyingyi@gmail.com on 25 Nov 2012 at 7:21

• Changed state: Invalid

[GoogleCodeExporter]

Issue 195 has been merged into this issue.

Original comment by buyingyi@gmail.com on 25 Nov 2012 at 7:45

[GoogleCodeExporter]

Yingyi,

This is indeed a bug. The fact that this function is implemented as an 
unnesting function only is an implementation detail. From the user's point of 
view AQL is a completely compositional language. Any expression is usable in 
any place an expression is expected.

There are a few strategies to fix this kind of a problem.

1. Functions should not be thought of as "unnesting" or "scalar" etc. Think of 
those types as being ways in which a function can be instantiated. There is no 
reason why a function cannot be instantiated in multiple roles. This is how 
VXQuery solves the problem -- The Function class provides a createXXXFactory() 
call where XXX can be ScalarEvaluator, UnnestingEvaluator, AggregateEvaluator 
etc. This way every function can be instantiated correctly based on which 
operator invokes in in algebricks.
2. Provide rewrite rules that convert an unsupported role of a function into a 
supported form -- In the current query this would mean that the let form is 
rewritten into the for form so that the semantics of the original query are 
maintained.

I would suggest (1) as it is much simpler and is guaranteed to work all the 
time.

Original comment by vinay...@gmail.com on 25 Nov 2012 at 7:58

• Changed state: New

[GoogleCodeExporter]

Vinayak,

  I see, in that way, a function can implement multiple evaluators and play different roles. I also vote (1) since it looks easier. 
  Thanks!

Best regards,
Yingyi

Original comment by buyingyi@gmail.com on 25 Nov 2012 at 8:07

• Changed state: Accepted

[GoogleCodeExporter]

Yingyi,
I had made changes (in asterix_stabilization)  in the preferred direction (1). 
AbstractFunctionDescriptor acts as an (abstract) base class and includes the 
methods 
createRunnintAggregateFactory(),  createSerializableAggregateFactory() etc. of 
the likes of createXXXFactory(), 
as pointed out by Vinayak. The base class has a default implementation the 
simply throws "NotImplemented' exception. Derived classes may implement any 
(and multiple) of such createXXXFactory() methods as desired. 
For .e.g RangeDescriptor currently implements createUnnestingFunctionFactory 
only, but may implement createEvaluatorFactory as well and then can be 
instantiated accordingly depending upon the context where it is used. 

Original comment by RamanGro...@gmail.com on 25 Nov 2012 at 8:51

[GoogleCodeExporter]

Vinayak, Raman,

   If we go with approach (1), I guess we also need to inline those variables if they are used.  Otherwise, we will end up doing unnecessary eager materialization.

   For example:
   let $x:=dataset("X")
   for $i in $x
   return $i;

   In that case, $x will materialize a list, which is not efficient and also a list may exceed the page size.
   Thanks!

Yingyi

Original comment by buyingyi@gmail.com on 25 Nov 2012 at 9:35

[GoogleCodeExporter]

Yingyi,

Inlining the function is an optimization and would be good to do when a 
function implements the role required for the inlining to work. Each function 
could expose the roles supported by it and rules could be implemented to inline 
into an unnest when a function implements the unnesting role. This is in some 
sense suggestion (2) above, but now its optional and for optimization rather 
than for correctness.

Original comment by vinay...@gmail.com on 25 Nov 2012 at 1:15

[GoogleCodeExporter]

Vinayak, 

   Ok, fair enough.  The inline rule seems not difficult to implement.

Yingyi

Original comment by buyingyi@gmail.com on 25 Nov 2012 at 8:21

[GoogleCodeExporter]

I fixed that in asterix_stabilization_printer.
Right now I use rewriting rule to inline unnest functions.
But as Vinayak said, the runtime function should be able to play different 
roles.
Raman, could you open another issue for runtime functions and fix the unnest 
runtime functions, e.g., range, scan-collection, etc?

Original comment by buyingyi@gmail.com on 28 Nov 2012 at 8:18

• Changed state: FixedInBranch

[GoogleCodeExporter]

Original comment by buyingyi@gmail.com on 7 Dec 2012 at 10:40

• Changed state: Fixed

[GoogleCodeExporter]

Yingyi/Raman - Was another issue reported to track, "fix the unnest runtime 
functions, e.g., range, scan-collection, etc?"

Original comment by khfaraaz82 on 18 Nov 2014 at 12:48