-
Notifications
You must be signed in to change notification settings - Fork 159
dataFilters, insert by default instead of merging #286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
couple of comments:
I think just doing inserts could be fine if and only if we add ability for some data (if in state data) to be immutable. |
I think you missed some detail here in what I wrote. Specifically:
It might have been more clear if I reversed the order of the operands for
Yes, I know this, but I wanted to make sure the example was very clear, I didn't want to leave anything to be assumed.
Consider this example from bash:
What do you expect the output of env to include? Now consider the following example with what you're proposing: toStateData: ${ .foo } Given the following action results: baz: 1 Given the existing state data of: foo: .bar Please take a moment to consider how a user might think that they should be getting the following output because the expression foo: .bar
bar:
baz: 1 Overall, I think there's something wrong about the way the spec is using the '${}'. In any other language I've seen, something like that is used for variable interpolation embedded in a string. In fact I think I saw examples where that's how it's being used (for example : I would propose the following be considered:
I'm not sure what we're trying to accomplish with immutability. |
@jorgenj it requires that the runtime make the state data available as a pre-defined jq variable
I think for pre-defining variables such as for example $env (environmental variables) is a good idea but that is best for immutable data which state data is not |
@jorgenj That is one of the things that the old dataInputSchema and dataOutputSchema props were trying to accomplish in a way (just covered "existence") |
This statement is confusing, the runtimes primary job is to keep track of the current state data over the duration of a workflow. It's unclear whether the difficulty here is around maintaining stateData (something the runtime already has to do) or whether it's about exposing a reference to that data in the chosen expression language.
In all of these cases, the runtime should have the stateData with the appropriate current content at the time of each of these events. This proposal doesn't seem to change that, no matter what the runtime has to merge the changes into the state in some specific order. Whether the current stateData is able to be referenced at each of these points or not doesn't seem to change what the runtime has to do. @tsurdilo wdyt? |
Judging by the lack of response, the answer is clearly that there's no point in trying to follow up further on this. |
I'd like to propose the following:
WHY?
Because this is much simpler to understand, there are no surprises about deep or shallow merging its just a simple insert by default. It also lets users leverage the power of JQ to do custom 'merge' strategies.
Consider the example:
This would simply insert the action result at the location .customer in state data. If something already exists there in state data, this would completely over-write that data.
What if users really want to do merge?
We can give users much more flexibility, though it requires that the runtime make the state data available as a pre-defined jq variable.
With that we can give the user all kinds of flexibility.
(These examples assume the action result, referenced by . is a customer object)
Here's an example where we do a simple merge via actionDataFilter:
The above example takes customer from stateData and shallow merges it with the action result, reassigning the results back to .customer in the state data.
Here's an example where we do a recursive merge via actionDataFilter:
The above example takes customer from stateData and recursively merges it with the action result, reassigning the results back to .customer in the state data.
The text was updated successfully, but these errors were encountered: