It would be nice if the ChangeDetector match all attributes could exclude unexposed workspace level attributes like multi_reader_id, multi_reader_full_id, multi_reader_keyword, multi_reader_type.
As it is, I need to either use match selected attributes and select them all (not possible in dynamic scenarios) or expose the multi_ attributes prior to the ChangeDetector so that match all except can be used.
Gathering Interest
ChangeDetector match all attributes should exclude multi_reader attributes
+40- Contributor
+51- Evangelist
I thought i had a similar suggestion for the matcher which also considered unexposed attributes if match all was selected (can't find the idea now) I
+40- Contributor
I don't like the idea of ignoring all unexposed attributes (for dynamic scenarios), but an additional parameter to "Consider unexposed format attributes: Yes|No" would be very interesting. Replace format with whatever word covers the multi_*, fme_*, csv_skipped_line, etc attributes.
That way if you don't know/care about format/reader specific attributes, you don't need to deal with them, but if fme_feature_type was important, you can expose it on the reader.
+1- Contributor
It is really necessary to exclude the Reader-Attributes!
I don't know any example where the Change-detector will be used with the same reader/table Name.
Using the same table from the same Reader will never Show any changes!
+17- Safer
Hi all,
We’re hoping to address this idea and want to validate our approach and make sure it’s addressing the needs here.
If the ChangeDetector had a Yes/No parameter to exclude format attributes (similar to the “Include Format Attributes” in the SchemaScanner) from 'Match All', would that solve your problem?
The format attributes would be: multi_reader_*, fme_* and any format prefixed attributes that are determined dynamically from multi_reader_* (eg if it detects csv, then csv_* attributes would be excluded). By going with this approach this would allow for your user attributes that are read as unexposed to still be used to check for changes.
+63
If the ChangeDetector had a Yes/No parameter to exclude format attributes (similar to the “Include Format Attributes” in the SchemaScanner) from 'Match All', would that solve your problem?
It would certainly be an improvement for me.
In our basic training course we have an excercise on change detection on two input shapefiles. Selecting “All Attributes” would seem logical, but that includes the fme_basename attribute, which always differs between the two sets. So we work around this by telling the trainees to use “Selected Attributes” and then select all visible attributes (because that list excludes the format and fme attributes)
+22- Enthusiast
AttributeExploder could do with something like this too, to avoid having to exclude the reader/format attributes we will never need - if desired.
+26- Enthusiast
I would like the ability to either also exclude “arcgisfeatureservice_*” and “*_resolved” fields or exclude unexposed attributes to be able to build dynamic workbenches with change detector.
I’m guessing the “arcgisfeatureservice_*” would be included as format attributes?
However, currently, my workbench is flagging “*_resolved” fields as updated even when I have Resolve Domains set to “No” in my feature reader. So I would have to expose all of these fields and then remove them before change detector which I am still struggling to figure out in order to build a dynamic workbench.
Login to the community
No account yet? Create an account
An FME Account is required to contribute
LoginEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.