Skip to main content

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

Certainly the doc seems to echo your thinking: https://docs.safe.com/fme/html/FME-Form-Documentation/FME-ReadersWriters/aboutFeatures/feat_type_reader_usrAttr.htm

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?


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. 


Reply