Jump to content

Provide original query


ctwise
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

"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. :-)

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...