When I use a PythonCaller (on build 16673) to set the feature type by calling
feature.setFeatureType('something')
it actually doesn't seem to do anything, because when I connect a FeatureTypeFilter transformer to the PythonCaller and filter on 'something', nothing comes out of that port.
Where kFMEFeatureTypeAttr resolves to the string 'fme_feature_type'.
But then what is the point of the setFeatureType() method?
Is this method actually not implemented, perhaps?
Best answer by daveatsafe
The FMEFeature.setFeatureType() method is not that useful within a workspace, since whatever feature type you set will be modified by the PythonCaller and subsequent transformers. In the workspace context, the generic attribute 'fme_feature_type' retains the original feature type from the reader, and is what the FeatureTypeFilter filters on.
However, in a purely FMEObjects context (ie. external Python, C# application), or if you are using a writer within the PythonCaller, the actual feature type set by setFeatureType() is what is used by the writers and pipelines, and not the contents of the 'fme_feature_type' attribute.
Just tested, can confirm that setFeatureType() doesn't seem to do anything re fme_feature_type, or any other attribute for that matter.
Hi David, thanks for your confirmation :)
Can anyone from Safe confirm this too? And maybe create a PR to either make the method work or remove it from the API? I think a fix makes more sense, since getFeatureType() does work.
In my observation, the "feature type" value that is treated with the set/getFeatureType method is different from "fme_feature_type" and also automatically changes every time the feature is output from a transformer. I'm wondering if the "feature type" and those methods have a special role in the internal processing of FME engine.
The FMEFeature.setFeatureType() method is not that useful within a workspace, since whatever feature type you set will be modified by the PythonCaller and subsequent transformers. In the workspace context, the generic attribute 'fme_feature_type' retains the original feature type from the reader, and is what the FeatureTypeFilter filters on.
However, in a purely FMEObjects context (ie. external Python, C# application), or if you are using a writer within the PythonCaller, the actual feature type set by setFeatureType() is what is used by the writers and pipelines, and not the contents of the 'fme_feature_type' attribute.
The FMEFeature.setFeatureType() method is not that useful within a workspace, since whatever feature type you set will be modified by the PythonCaller and subsequent transformers. In the workspace context, the generic attribute 'fme_feature_type' retains the original feature type from the reader, and is what the FeatureTypeFilter filters on.
However, in a purely FMEObjects context (ie. external Python, C# application), or if you are using a writer within the PythonCaller, the actual feature type set by setFeatureType() is what is used by the writers and pipelines, and not the contents of the 'fme_feature_type' attribute.
Thanks Dave, that is some very useful information.
I also noticed the "inconsistent" behavior there. I was hoping to use the setFeatureType() method to "tag" output features in my PythonCaller so I could filter on them afterwards using the FeatureTypeFilter, but I guess I need to use the 'fme_feature_type' attribute for that then. But now I know I could basically set any attribute and just use an AttributeFilter instead...
Thanks Dave, that is some very useful information.
I also noticed the "inconsistent" behavior there. I was hoping to use the setFeatureType() method to "tag" output features in my PythonCaller so I could filter on them afterwards using the FeatureTypeFilter, but I guess I need to use the 'fme_feature_type' attribute for that then. But now I know I could basically set any attribute and just use an AttributeFilter instead...
If you haven't already, feel free to vote for this idea, which is kind of related:
In fact, I would love to expand that idea by having any number of custom in- and output ports for the PythonCaller (similar to the new FeatureWriter for instance) that each receive their own method (not just input(self, feature)). If that doesn't require a major overhaul of the API, of course...
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
