Changes between Initial Version and Version 1 of Ticket #30138, comment 7


Ignore:
Timestamp:
Jan 7, 2020, 4:10:55 PM (5 years ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30138, comment 7

    initial v1  
    55Implementing 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.
    66
    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.
     7I 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.
    88
    99In 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.
Back to Top