[
https://issues.apache.org/jira/browse/PIG-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888073#action_12888073
]
Aniket Mokashi commented on PIG-1434:
-------------------------------------
I mean the cases where users type in some alias which are currently not
possible to include inside a foreach statement and accidentally getting them
treated as scalar by pig and then failing scripts at runtime (and may not fail
in one-liner sample cases).
For example-
Y = foreach Z generate C.$0; where C is not a scalar. Currently, this would
throw an error upfront, for erroneous usage (logical (do not know restrictions
on foreach statement) or typing mistake) of C, But, after we add support of
scalars, pig may conclude C to be used as a scalar and generate the plans
accordingly.
By introducing square bracketed syntax we can make sure that user intended to
use C as a scalar and it wasn't introduced by mistake.A cast would also work
for this, but as we have introduced scalar projections (C.count, C.max etc), we
already have cases wherein user may mean to cast fields(count, max) rather than
scalars themselves.
> Allow casting relations to scalars
> ----------------------------------
>
> Key: PIG-1434
> URL: https://issues.apache.org/jira/browse/PIG-1434
> Project: Pig
> Issue Type: Improvement
> Reporter: Olga Natkovich
> Assignee: Aniket Mokashi
> Fix For: 0.8.0
>
> Attachments: scalarImpl.patch
>
>
> This jira is to implement a simplified version of the functionality described
> in https://issues.apache.org/jira/browse/PIG-801.
> The proposal is to allow casting relations to scalar types in foreach.
> Example:
> A = load 'data' as (x, y, z);
> B = group A all;
> C = foreach B generate COUNT(A);
> .....
> X = ....
> Y = foreach X generate $1/(long) C;
> Couple of additional comments:
> (1) You can only cast relations including a single value or an error will be
> reported
> (2) Name resolution is needed since relation X might have field named C in
> which case that field takes precedence.
> (3) Y will look for C closest to it.
> Implementation thoughts:
> The idea is to store C into a file and then convert it into scalar via a UDF.
> I believe we already have a UDF that Ben Reed contributed for this purpose.
> Most of the work would be to update the logical plan to
> (1) Store C
> (2) convert the cast to the UDF
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
