Skip to main content

Checking this, but surely this has to be a Bug?

 

FeatureJoiner in Left Join Mode and Right Hand Side Conflict Resolution is overwriting LHS Attributes with NULLs where:

a) There was no matching Feature on the RHS

b) The Attribute Name exists on both the LHS and the RHS

 

I would have thought that for any Left Feature that did not match any Right Feature, there is no "conflict" to resolve and it should exit the Transformer with the same Attribute Values as what it went in with?

capture

 

In your example, all the features on the Left are being joined with the feature on the right, which is why the attributes are overwritten. If they weren't joined they'd be coming out the UnjoinedLeft port


In your example, all the features on the Left are being joined with the feature on the right, which is why the attributes are overwritten. If they weren't joined they'd be coming out the UnjoinedLeft port

That would be True if FeautreJoiner was in Inner Join Mode, but it isn't the case when it is in Left Join Mode.

 

Left Mode is roughly equivalent to a Left Outer Join in SQL and the FME Help describes Left Join Mode outputting features to the Joined Port as:

  • "Features that have matching Left and Right pairs, AND"
  • "All other unmatched Left features."

 

In other words, the unmatched Left features should exit the Joined Port without change?


In your example, all the features on the Left are being joined with the feature on the right, which is why the attributes are overwritten. If they weren't joined they'd be coming out the UnjoinedLeft port

Hmmm, reading the documentation further, it is actually more ambiguous than I thought.

 

The question is whether or not Attribute Conflict Resolution should apply to Unmatched Features, given there is no Attribute value conflict in unmatched features to resolve.....not in a traditional FME Feature-by-Feature sense anyway.

 

The bit in the Help that is ambiguous is:

"A Left join includes complete joins, plus Left features that did not find matches - that is, all Left features, joined or otherwise Output is:

  • Joined: All pairs of Left and Right features that have matching values for the Join On keys, including attributes from both Left and Right matching features. Additionally, unmatched Left features are output here. They will have the same attribute names added to them as the matched features, but with null values."

 

....so it is saying the Joined Port is outputting "Joined" features and "Otherwise" features (Unmatched features). It says that for Unmatched Features, Attributes are "added" as NULLs if they are on the RHS but not present in the LHS Schema, but does not state for Unmatched Features that LHS Attributes will be replaced if they have the same name as as an Attribute on the RHS.

 

"Attribute Conflict Resolution: When a joined feature receives an attribute with the same name (or a common attribute) from both the left and right features, this specifies which value should be preferred for the Joined output."

 

The description makes sense for "Joined" features, but this implies that it is only for where there is a match between the Left and the Right hand side. However..............you could also read it as being "Joined Port" Features. That's the ambiguity.


The above in the Help description and Test Workflow got me thinking more. What happens with Lists of the same name?

 

Here is what happens to Unmatched Features in Left Join Mode. Part of the List is overwritten and part is left intact!

 

Unmatched Left Feature before entering FeatureJoiner

capture

Unmatched Left Feature after exiting FeatureJoiner, with 2 of the 6 list items getting NULL'ed!

capture1

 

This also teaches me one other thing about FeatureJoiner. That generally Lists should be stripped out of the Features before passing them through FeatureJoiner in order to not get wonky lists!


Reply