I propose a simple but elegant solution: PLEASE ADD AN ADDITIONAL SETTING ON THE SETTINGS TAB OF EACH MODULE CALLED “Include Input with Output”. When that setting is turned on, instead of just outputting the results as an array of objects, the output should be an array of objects that always have two properties, input and output.
So for example: suppose I have two schools with IDs 5 and 6. Alice and Bob teach at school 5, and Carol and Daniel teach at school 6. I use a mySQL query to tell me how many students are in their classes: Select teachername, sum(students) as pop where school_id = {{ $json.school }} group by teachername
In this scenario I have two input items:
[
{"school": 5},
{"school": 6}
]
and four output items:
[
{"teachername": "Alice", "pop": 20},
{"teachername": "Bob", "pop": 18},
{"teachername": "Carol", "pop": 23},
{"teachername": "Daniel", "pop": 21},
]
That is, currently the downstream module has no idea which school each result is referring to. Without doing some tricks to include the school in the output, there would be no way to use a merge node to stitch them back together downstream. (I know, since this is a custom query I -could- include the school in the results, but in general we rarely have that kind of control over result data structure.)
What I propose is that for modules where this setting is turned on, downstream modules still see four items, but each item contains both the output -and- the corresponding input:
[
{"input": {"school": 5}, "output": {"teachername": "Alice", "pop": 20} },
{"input": {"school": 5}, "output": {"teachername": "Bob", "pop": 18} },
{"input": {"school": 6}, "output": {"teachername": "Carol", "pop": 23} },
{"input": {"school": 6}, "output": {"teachername": "Daniel", "pop": 21} },
]
That is, it’s immediately obvious in every item what input values caused what output. No need for a merge, no need for guessing how to link the output with the input after the fact.
By implementing this within the “settings” shell, we’d get the same behavior in all of the modules that have a one to many relationship between input & output (mySQL, Postgres, HTTP, Airtable, etc etc etc).
Very importantly, it should also carry through to error output if that’s enabled. So when a module gets 100 inputs and 5 of them cause an error, we don’t have to bend over backwards to figure out which inputs were ok and which ones triggered an error, and we could figure out how to handle the error by considering BOTH the input and the error output simultaneously.
Best of all workflows wouldn’t be FULL of merges, they’d just follow a simple linear progression that visually mirrors the developer’s logic.
If you like this idea, please upvote so it gets some visibility with the N8N team!
Lee
