Closed GoogleCodeExporter closed 8 years ago
Original comment by khfaraaz82
on 17 Sep 2012 at 7:57
Original comment by khfaraaz82
on 16 Oct 2012 at 6:04
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
Issue 195 has been merged into this issue.
Original comment by buyingyi@gmail.com
on 25 Nov 2012 at 7:45
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
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
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
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
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
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
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
Original comment by buyingyi@gmail.com
on 7 Dec 2012 at 10:40
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
Original issue reported on code.google.com by
RamanGro...@gmail.com
on 15 Sep 2012 at 8:18