Changes between Initial Version and Version 1 of Ticket #30138, comment 7
- Timestamp:
- Jan 7, 2020, 4:10:55 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #30138, comment 7
initial v1 5 5 Implementing this in a proper manager would likely require a lot of work. It would require `ignore_conflicts` to accept an iterable of constraint names or tuple of fields corresponding to `Field.unique=True` or `Meta.unique_together` definitions. These entries could then be matched to constraint names and used as `conflict_target` in the `ON CONFLICT` clause and in the join `USING` clause. I think we'd also like to allow exclusion constraints to be treated differently because joining on fields won't help here as an insert could be conflicting with more than one result. 6 6 7 I assume callers would also like to be able to differentiate between newly inserted and conflicting entries so the return value of `bulk_create` would need to be formalized/changed. 7 I assume callers would also like to be able to differentiate between newly inserted and conflicting entries so the return value of `bulk_create` would need to be formalized/changed. I assume we'd like to return a list of tuple of the form `(bool: inserted, Model: instance, List[Model]: conflicting_instances)` and only assign the `pk` on non-conflicting rows. 8 8 9 9 In summary this ticket involves a lot of research work to get right and not paint ourselves in a corner with regards to the desired API.