I need to change the order in which features are sent out of an AttributeFilter, because they eventually get set to SQLExecutors which will fail if not processed in the right order (due to database constraints). I have seen questions & answers regarding the port order of custom transformers, but is there a way to control the order in which the features will leave an AttributeFilter? The image shows the situation - the features seem to come out of the InterFeatureLink port first, but they actually have to wait until the features from the RoundPipe port have exited and been executed on the database.
Question
Change order that features leave an AttributeFilter
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
Update: I was able to solve this particular issue by putting a FeatureHolder between the InterFeatureLink and its SQLExecutor. This works for now but I would really like to know if there is a more elegant way of doing this, as I foresee a lot more of these situations arising in this workflow and I can only imagine the headaches that are in store for me with an elaborate series of FeatureHolders
+60- 2939 replies
I doubt this solution guarantees a correct order, maybe it works for now but different with a heavier dataset.
Not sure if this is the best way but I would put a FeatureHolder behind SQLExecutor_3, connected on the Initiator port. Then a Sampler, releasing the first feature when all features are released by the FeatureHolder. Then strip all attributes and geometry and send it to a FeatureMerger Supplier input port. Merge using 1=1 with the IneFeatureLink features. Merged output port to SQLExecutor_4.
Curious what others use for the order problem.
+2- Contributor
- 606 replies
Update: I was able to solve this particular issue by putting a FeatureHolder between the InterFeatureLink and its SQLExecutor. This works for now but I would really like to know if there is a more elegant way of doing this, as I foresee a lot more of these situations arising in this workflow and I can only imagine the headaches that are in store for me with an elaborate series of FeatureHolders
Hi @iboates,
Another option for controlling the flow of features is to use a blocking transformer like the Sorter. This will also allow you to control the order in which individual features are passed into the SQLExecutor.
The Blocking Transformers and the Flow of Features and In what order are features processed when there are parallel transformers articles might also be a good resource in the future!
+22- Contributor
- 2179 replies
Just an idea I have used before:
After the AttributeFilter, add an AttributeCreator to create a priority attribute (with value 1, 2 or 3).
Merge all lines together in a Sorter, sorting on priority.
Then use an other AttributeFilter to split on priority and pass features to different SQLExecutors.
Hope this helps.
+22- Contributor
- 2179 replies
Another transformer to look at is the Decelerator.
Not a nice solution, but sometimes (and maybe in this case) useful.
It simply waits an amount of time before passing on features.
Not the best solution if performance is an issue.