1420 runbrokerquery management command is broken#1422
Conversation
| name.full_clean() | ||
| name.save() | ||
|
|
||
| if not created: |
There was a problem hiding this comment.
Does anybody know why we don't run post_save_hooks on new targets?
I'm not eager to tear down a Chesterton Fence...
There was a problem hiding this comment.
As long as this stays in, I believe this also closes #661
There was a problem hiding this comment.
This was added in 2019 v1.2.0 with the "initial" version of post save hooks. (technically this was added in a fix that reverted to an older version of post_save_hooks but the result is the same)
I see no discussion or explanation for why it was done this way.
|
Just to make sure I'm understanding correctly, if there is a match between a new alert and an existing target, this will just write a warning to the log and move on to the next alert, correct? Eventually we would want it to add info from the new alert to the existing target, but that can be a separate issue. |
This is correct. We have a branch in development right now for data services that updates Reduced Datums for existing targets, and an issue that will allow you to update target model information, thought this is a more interactive process than could probably be done from a management command. |
griffin-h
left a comment
There was a problem hiding this comment.
I can confirm that this runs as expected now! I haven't had a chance to test the validate_unique portion yet, but I consider that just a bonus for now.
Actually I take it back, I realized I could just run the management command again and get a bunch of duplicates to test. This is the warning message that gets printed: |
This updates the runbrokerquery management command to validate unique targets, use the modern returns form to_target, and run post save hooks even for new targets.
Because I'm bad at git, this also includes updates to the Pillow and Cryptography dependencies.