On 29 Jul 2014, at 17:13, Fabian Hueske <[email protected]> wrote: > 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.
I actually said/wanted to say that it is *not* correct, because it breaks the join semantics, but that it is useful for the insertion use case. > 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). I think Stephan explicitly referred to Sebastian and wouldn't expect a normal user to look at the plan. ;-) > Is this behavior documented somewhere? If not, we should definitely add it. > 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. +1 I agree that we should make this more explicit. If we added further joins we wouldn't need an extra `joinWithSolutionSet`, but the user would pick the one she wants.
