Group Splitter Node

[takbb]

Hi @iCFO ,

I can see an automated split might make it simple to split the rows, but would you generally have a use case where you are splitting rows but not then wanting to do some very specific handling/transformation for each of them, in which case I would think you’d want to explicitly state which rows were going to each of the split branches.

Don’t you normally need to know at design time which rows are going to each branch?

As a prototype, the following construct would do what you are suggesting, I think, with the variable then being used to populate the component’s “str-filter-patterns” list.

There would be no need to specifically find the first 10, as the component will just ignore any additional items, so that gets handled easily.

I guess it could be built in to the component, but I’m wondering if it is really that useful. Open to thoughts as it could be you would have a common need for this that I’m missing.

[iCFO]

Good point. Populating from a list is really only viable for temporary workflows or a static table. Any updating source would have outputs jumping around if there were changes to the unique values. This is the kind of thing that drove me to creating component log files that allow the user to write, read back and backup hardcoded component settings. Complex and a massive overkill for something like this, but another example of how beneficial it is to be able to incorporate memory into components. I would love to have a simpler native solution for manually triggered read / write data log operations. I have only pulled off the necessary resetting “one off” action in the interactive view though. I believe that the platform is built on the concept that config settings persist, and will not allow a one time action.