-
Notifications
You must be signed in to change notification settings - Fork 41
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
feat(src): add support for appending to existing outputs #932
feat(src): add support for appending to existing outputs #932
Conversation
it('computes simple tree with append and execute plugin.', async () => { | ||
const tree = { | ||
children: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will need more tests to cover aggregation, group by behaviour - once we've agreed what the behaviour should be
Hi @jamescrowley - just back from vacation today - looking forward to checking this out tomorrow. Thanks for your efforts! |
Hi @jamescrowley great point about aggregation and time-sync. I think the only behaviour that makes sense is to re-run the aggregation / time-sync over the new data and overwrite whatever is already present. The "right" way to use append would probably be for the user to toggle time-sync and aggregation on some final manifest file after all the append actions have been taken, but in cases where a user is appending to an already-synced-or-aggregated manifest, the time-sync and/or aggregation should be repeated with the new input data, with the results overriding the original. re It's ok having this as an amendment to the core execution logic - I don't think it makes sense as a plugin/builtin or other extension. |
also tagging in @narekhovhannisyan for visibility |
👍 I’ll rebase and add some tests to try and capture that behaviour |
Signed-off-by: James Crowley <[email protected]>
@jmcook1186 I'm working through regroup as there's a few things to suss out there, but in the meantime, some questions re documenting the aggregation behaviour w/ tests:
As I see it the options are: Thanks! |
Hi @jamescrowley - looping in @narekhovhannisyan who can give better answers to these questions! |
54712f1
to
091d583
Compare
@jmcook1186 @narekhovhannisyan also FYI on the regroup, I think the behaviour that makes most sense is to regroup outputs in addition to inputs when in append mode - otherwise we can't sensibly add the new outputs if the existing outputs aren't grouped. I'll push up some commits once I've ironed out the kinks but let me know if you object on principal and think I should go another way! |
I don't object on principle - do you have an opinion @narekhovhannisyan? |
Signed-off-by: James Crowley <[email protected]>
Signed-off-by: James Crowley <[email protected]>
Signed-off-by: James Crowley <[email protected]>
Signed-off-by: James Crowley <[email protected]>
appendGroup already returns acc merged anyway Signed-off-by: James Crowley <[email protected]>
only when appending - otherwise outputs are lost if not already grouped. Signed-off-by: James Crowley <[email protected]>
I've pushed proposed changes.
|
Hey @jmcook1186, @jamescrowley. sorry for late reply. Will check the threaд and will get back with the results. |
Hi @jamescrowley sorry it's taking a while to get this reviewed - we've got some somewhat urgent features to ship to support a demo in a couple of weeks, but I'm keen to get into this asap. I'm planning to check out your branch and start looking into it later today. Cheers |
Hi @jamescrowley - i checked out the branch yesterday and am having trouble making the append feature work - could you please provide an example manifest and run command combo that works for you so I can try to replicate locally? |
@jmcook1186 I was just running the second example in the original ticket (with original inputs, and modified mock observations for a later time), with the compute/group updated for the latest syntax
and running
you then get output:
which includes the additional outputs. Ideally would include this as an integration test if we can codify how we want to pass 'append' into the tests. Let me know if you get the above, or if I've misunderstood somewhere along the way. |
got it - thanks, yes I have consistent results to you now. Will dig in and try to understand your changes a bit more today - all seems to behave as expected so far. Then will pass to @manushak to approve. |
Hi @jamescrowley, I've reviewed the PR, and it seems the append works only once. I've recorded a short video. In the video, it is shown that the last output data from 04-07 is missing |
@manushak Thanks for taking a look. The current implementation appends to the outputs that already exist in the input manifest, but it does not append to any outputs that exist in a separate output manifest if supplied - that is always overwritten. So in the example given, if you then supplied append-output.yaml as the input manifest for the second run (having modified the mock parameters) then it would behave as I believe you desired. If the intent is to append to both outputs on the input manifest and outputs to an existing output manifest (if it exists) I’d need to do some more digging - and probably clarify with you all on other scenarios needing support here. Hope that makes sense! |
Yeah, you're right, @jamescrowley. I'm sorry for the misunderstanding. It works as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this, James!
Types of changes
A description of the changes proposed in the Pull Request
Closes #845.
A few areas to discuss/agree: