#34943: Support passing unique constraint names to bulk_create().
-------------------------------------+-------------------------------------
Reporter: Alex Vandiver | Owner: Sujay
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: bulk insert update | Triage Stage: Accepted
upsert |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by HAMA Barhamou):
Replying to [comment:3 Simon Charette]:
> Maybe the would be an opportunity to deprecate/rename the
`unique_fields` kwarg name to `unique_expressions` or `unique_together` to
denote that not only fields are acceptable here.
>
> Or we could take an hybrid approach like we did with `Index` and
`Constraint` where either allow `update_fields` or `update_expressions` to
be specified.
>
> I get a sense that we should have preferred a `unique_constraint` kwarg
that points to the name of an entry of `Meta.constraints` or the name of a
`Field(unique)` in the first place instead of forcing users to specify the
exact same index definition they have in their model,
`Meta.unique_together`, or `Meta.constraints` instead.
>
> For backends that support the `ON CONFLICT ON CONSTRAINT` clause we
could have simply used it for the constraint name specified otherwise we
know what the index expression associated with the specified constraint is
so we can generate the proper SQL.
>
> In other words, for a model like
>
> {{{#!python
> class UserTopic(models.Model):
> ...
> class Meta:
> constraints = [
> UniqueConstraint(
> 'user_profile_id','stream_id',Upper('topic_name'),
> name='unique_profile_stream_topic'
> )
> ]
> }}}
>
> The call to `bulk_create` could simply have been
>
> {{{#!python
> UserTopic.objects.bulk_create(
> [ut],
> update_fields=['last_updated','visibility_policy'],
> unique_constraint='unique_profile_stream_topic',
> )
> }}}
>
> ---
>
> My recommendation would be to introduce a `unique_constraint: str |
tuple[str | Expression]` kwarg and deprecate `unique_fields`. When
provided a `str` it would be a reference to a `UniqueConstraint` by
`.name` and when it's a `tuple` it would be expected to be a index
expression where `str` are resolved to field names.
>
> I guess the `str` -> `UniqueConstraint.name` part could be a distinct
feature request but it seems related to this issue given the only way
Django supports creating unique constraints composed of expressions is
through `Meta.constaints` and having to define the exact expression twice
is error prone.
Hi, If you depreciated unique_fields, what would that mean for ticket
#34277 [https://code.djangoproject.com/ticket/34277], which I'm working
on?
--
Ticket URL: <https://code.djangoproject.com/ticket/34943#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018e1ed472a9-614e7068-95df-4f7a-ab27-b1b13840a2c7-000000%40eu-central-1.amazonses.com.
