Multiple Join Matches

Every time a feature on the Left matches one on the Right, a new feature is output from the Joined port. This means that where there are multiple matches for a single Left (Requestor) feature, there will be multiple output features.

This is why the FeatureJoiner has no equivalent to the FeatureMerger “handle duplicate suppliers” parameter. It does not need this. It just creates a new Joined feature for each duplicate supplier.

To understand this, let’s take a look at this with some feature count numbers included:

There are eight (8) facility features and 1,463,442 addresses. How many features will exit the Joined port? Well, it depends.

If we assume a strict 1:1 match between each Facility and an Address, then 8 features will exit as Joined. Why? Because we have 8 matches. Depending on the mode the count will be one of these:

However, we might not have such a clean 1:1 match between Facility and Address table. We could have 1:M, M:1, or even M:M.

Let’s say each Facility has two matches in the Address table. Then we get this:

Why are we getting more features out than we put into the Left port? Because we are getting one feature per match, and there are 16 matches!

This is not something the FeatureMerger would do. It would either ignore the second match or create a list. But this is designed to be a SQL equivalent, and so it works differently. In fact – in an extreme case – if we assumed that every Facility has AddressID=1, and every Address has AddressID=1, then every facility would match to every address!

That would give us 8 x 1,463,442 = 11,707,536 matches

If you did want the same as the FeatureMerger would give - one matched record with a list of matches - then you simply need to create a list with a ListBuilder grouping by your join keys.