[ https://issues.apache.org/jira/browse/PIG-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14360607#comment-14360607 ]
William Watson commented on PIG-4458: ------------------------------------- Well, the user already controls the key order. That was just an example of a thing that's not being explicitly forbidden with an exception. Did you look at my patch? It removes the UDF check completely and I also removed the test that would fail when a UDF is in the FOREACH. Are you saying I should write a new test that makes sure that UDFs don't blow up the code? I don't feel that's necessary, but I can if that's the consensus. > Support UDFs in a FOREACH Before a Merge Join > --------------------------------------------- > > Key: PIG-4458 > URL: https://issues.apache.org/jira/browse/PIG-4458 > Project: Pig > Issue Type: New Feature > Reporter: William Watson > Attachments: remove_merge_join_udf_restriction.patch > > > Right now, the MapSideMergeValidator outright rejects any foreach that has a > UDF in it: > {code} > private boolean isAcceptableForEachOp(Operator lo) throws > LogicalToPhysicalTranslatorException { > if (lo instanceof LOForEach) { > OperatorPlan innerPlan = ((LOForEach) lo).getInnerPlan(); > validateMapSideMerge(innerPlan.getSinks(), innerPlan); > return !containsUDFs((LOForEach) lo); > } else { > return false; > } > } > {code} > There is a TODO for this later on in that same class (inside containsUDFs): > {code} > // TODO (dvryaboy): in the future we could relax this rule by tracing what > fields > // are being passed into the UDF, and only refusing if the UDF is working on > the > // join key. Transforms of other fields should be ok. > {code} > We should do the TODO and relax this requirement or just remove it altogether -- This message was sent by Atlassian JIRA (v6.3.4#6332)