[ https://issues.apache.org/jira/browse/PIG-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16331344#comment-16331344 ]
Rohini Palaniswamy commented on PIG-4608: ----------------------------------------- bq. a = FOREACH b UPDATE q AS q:int – This should be illegal, right? If the type is changed, an explicit modify of the value should occur That should be supported after PIG-2315 (not pulled into our internal Y releases). [~knoguchi] can confirm. bq. This should be illegal, right? No types should be present in a DROP statement yes. bq. flattening a tuple into existing fields - does this make sense Not sure if there is a use case, but don't see a problem against adding support for it. What happens if $5 has more than 3 fields? I am assuming it will be something like a = FOREACH b UPDATE q with $5.f1 , r WITH $5.f2 , s with $5.f3 as t; bq. flattening a bag into existing fields, exploding rows in the process You will have to add support for maps as well. > FOREACH ... UPDATE > ------------------ > > Key: PIG-4608 > URL: https://issues.apache.org/jira/browse/PIG-4608 > Project: Pig > Issue Type: New Feature > Reporter: Haley Thrapp > Priority: Major > > I would like to propose a new command in Pig, FOREACH...UPDATE. > Syntactically, it would look much like FOREACH … GENERATE. > Example: > Input data: > (1,2,3) > (2,3,4) > (3,4,5) > -- Load the data > three_numbers = LOAD 'input_data' > USING PigStorage() > AS (f1:int, f2:int, f3:int); > -- Sum up the row > updated = FOREACH three_numbers UPDATE > 5 as f1, > f1+f2 as new_sum > ; > Dump updated; > (5,2,3,3) > (5,3,4,5) > (5,4,5,7) > Fields to update must be specified by alias. Any fields in the UPDATE that do > not match an existing field will be appended to the end of the tuple. > This command is particularly desirable in scripts that deal with a large > number of fields (in the 20-200 range). Often, we need to only make > modifications to a few fields. The FOREACH ... UPDATE statement, allows the > developer to focus on the actual logical changes instead of having to list > all of the fields that are also being passed through. > My team has prototyped this with changes to FOREACH ... GENERATE. We believe > this can be done with changes to the parser and the creation of a new > LOUpdate. No physical plan changes should be needed because we will leverage > what LOGenerate does. -- This message was sent by Atlassian JIRA (v7.6.3#76005)