SQLITE Reader and FeatureMerger - User Attributes behavior

  • 12 February 2024
  • 2 replies

Badge +9

When using the SQLITE3 Reader, unchecked attributes from the User Attributes tab are not exposed downstream to any transformer like AttributeManager, -Remover, -Keeper. This behavior is as expected.

However when using the FeatureType downstream on the Requestor side of a FetureMerger and the conflict resolution is set to ‘Use Requestor’ , the unchecked attribute is still active behind the scene and take precedence over the attribute of the same name coming from the Supplier.

It turned out that I need to keep the unwanted attribute ‘checked’ and remove it actively with an AttributeRemover to avoid the unexpected usage in the FeatureMerger.

I also tried to force it by changing the workspace option Reader/Writer Options > Allow Reader Feature Type Editing, but it made no difference.

Question: is this a bug or dangerously intended?


Setup: FME Forms 2023.2 for win 64

2 replies

Userlevel 4
Badge +25

Certainly the doc seems to echo your thinking:

In my experience the behavior of this feature is very much format dependent. For example a database format typically works this was as expected - just reads what is checked - but for other formats I've noticed they are just not exposed (as you've seen). 

Not that this is helpful, but I personally almost never use this feature and choose to modify the attributes myself in the workflow with Managers/Keepers - and a big part of that decision I think is the inconsistently between formats.

Hard to say if this is a bug or by design though. My guess is that it's half way between.

Perhaps @nampreetatsafe or @markatsafe is able to comment?

Badge +9

I think it’s acceptable that data formats have different capabilities in terms of attribute behavior when they got read by FME. However I would expect to see the user attribute check boxes disabled for formats where check/un-check can not be supported for technical reasons.