-
Notifications
You must be signed in to change notification settings - Fork 18
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
IVS-235 - Bulk insert ModelInstances #326
IVS-235 - Bulk insert ModelInstances #326
Conversation
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.
I think the combination of ModelInstance and ValidationOutcome bulk_creation better be wrapped in a transaction.atomic? Just so that the chance of orphaned instances is reduced even more.
Also, I still don't really know how this now actually works with transactions across multiple tasks in parallel and the isolation level of the transactions. It would be good to at least conceptually understand when multiple tasks in parallel try to create the same instances simultaneously. Should we set the isolation level to Serializable
?
ValidationOutcome.objects.bulk_create(outcomes_to_save) | ||
outcomes_instances_to_save = list() | ||
|
||
if outcomes_to_save: |
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.
if outcomes_to_save: | |
if outcomes_to_save and context.validation_task_id is not None: |
Any reason why you removed the ... and context.validation_task_id is not None
? The code is a bit spaghetti with all the operating modes, I guess it doesn't hurt to keep it in?
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.
it's at best redundant, worst it silently fails because of a failed assertion (has outcomes, but somehow task_id is lost?) and I prefer to bomb out loudly :-)
Co-authored-by: Thomas Krijnen <[email protected]>
Co-authored-by: Thomas Krijnen <[email protected]>
There is a transaction.atomic block at line 109, no harm to push it down, but has same effect?
|
Requires DB constraint to be in place to prevent duplicates / FK constraint errors
(see PR 27)