OK, let me summarize. Ufuk says, that is correct because a user might want to insert a new element into the solution set and therefore should check for null in the UDF. And Stephan adds that a user should check the plan if a null is passed to the UDF unexpectedly (which was the reason in our case due to incorrect annoations).
Is this behavior documented somewhere? Does it make sense to use the regular API join method for this or should we rather make the join with a solution set more explicit? Can we "force" the user to do iteration.getSolutionSet().joinWithSolutionSet(myData) instead of myData.join(iteration.getSolutionSet())? In that case we could make this behavior more explicit by using another method name and could also prevent that a user calls any other method than join or coGroup on a solution set which is prohibited right now. 2014-07-29 15:58 GMT+02:00 Stephan Ewen <[email protected]>: > Ufuk is right, that is intentional right now. > > If you get a null and do not expect it, check the program. Or in your case, > the plan from the optimizer ;-) >
