Provide original query

[ctwise]

When creating a pipeline of actions you lose the original value of {query} in later stages. This is correct but it would be useful to have access to the original query, e.g., {original-query}, regardless of what changes have been made in the pipeline.

[jdfwarrior]

You could always set the value of {query} to two variables first and then only work with the second variable that way you can preserve the original value in the first variable throughout execution.

[ctwise]

The problem isn't in a single script, it's between workflow components. For example, if I have a script filter followed by a script to handle the result of the script filter and want a notification at the end along the lines of 'Uploaded file {original-query} to {query}'. I can't do it. I can get halfway there by returning the whole notification line as the value of the script _after_ the script filter, but even then I've already lost the original query and have to go through gyrations in the script filter to compensate.

[phyllisstein]

The problem isn't in a single script, it's between workflow components. For example, if I have a script filter followed by a script to handle the result of the script filter and want a notification at the end along the lines of 'Uploaded file {original-query} to {query}'. I can't do it. I can get halfway there by returning the whole notification line as the value of the script _after_ the script filter, but even then I've already lost the original query and have to go through gyrations in the script filter to compensate.

 

I think you could still manage that with multiple variables. In my scp workflow, for example, the script filter passes something like 'path "{servername}" "{filepath}"' to the next stage, a script action that calls "python act.py {query}". The query is then understood as multiple arguments by the script, and as much or as little information as I need is preserved. E.g., one of the actions' arguments winds up being 'add "{name}" "{user}" "{pw}" "{address}" "{path}" "{url}"', and the script action's final output to a notification is "Saved {user}@{address}." If you're not calling a script from the command line, you could just split a given {query} by spaces or another character, and pass a full query like "{original-query} {new-component}" to a script action.

[ctwise]

"If you're not calling a script from the command line, you could just split a given {query} by spaces..."

 

Yes I could. But instead of injecting it into every step in the workflow, it would be easier and cleaner to provide the original query. Hence my request. :-)

[aiyo]

One input and one output for each module in a workflow makes it easy to understand and use.

Also it is possible to connect multiple triggers and script modules to one script module so the modules cannot have a "knowledge" of the pipeline they are in.

 

And as phyllisstein David said, you can always nest your queries with a delimiter and pass them on to the next module...

[ctwise]

One input and one output for each module in a workflow makes it easy to understand and use.

Also it is possible to connect multiple triggers and script modules to one script module so the modules cannot have a "knowledge" of the pipeline they are in.

 

And as phyllisstein David said, you can always nest your queries with a delimiter and pass them on to the next module...

 

If I embed the information in the value returned by an earlier stage that couples later stages _more_ tightly, not less.