#33912: In the admin, saving an object in a non-default database with unique
field
fails when the default database contains an object with the same unique
field value but different PK
----------------------------------+--------------------------------------
Reporter: François Granade | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 4.0
Severity: Normal | Resolution:
Keywords: admin multidb | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------
Changes (by François Granade):
* cc: François Granade (added)
* keywords: => admin multidb
* component: Uncategorized => contrib.admin
* type: Uncategorized => Bug
Old description:
> Reproducible using the test project in https://github.com/farialima
> /django-multidbbug . See README.md on how to run it.
>
> The steps are:
> - a model with a unique string field (beside the default int PK)
> - two DBs in the settings (`default` and `other`)
> - two objects in the default DB with PK 1 and 2, and some unique value
> for the unique string field
> - a object in the other DB (thus, with PK 1) with a different unique
> string field value
> - in `admin.py`, point the UI to the other database for the model (using
> https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#exposing-
> multiple-databases-in-django-s-admin-interface)
> - in the admin, try modifying the object in the other DB, giving it the
> same unique string value as the object with PK 2 in the default database
>
> => saving fails with error "Parcel with this Tracking id already
> exists.", see screenshot.
>
> The underlying issue is clearly that the admin will try to verify in the
> default DB that the objects doesn't exist. I think that the admin should
> *not* look in the default DB, as I set it up to only use the 'other' DB
> for my model...
>
> ```
> % poetry run ./manage.py shell
> (...)
> >>> from multidbbugapp.models import Parcel
> >>> print(Parcel.objects.all())
> <QuerySet [<Parcel: id=1, tracking_id=one>, <Parcel: id=2,
> tracking_id=two>]>
> >>> print(Parcel.objects.using('other').all())
> <QuerySet [<Parcel: id=1, tracking_id=two-duplicate>]>
> >>> o = Parcel.objects.using('other').first()
> >>> o
> <Parcel: id=1, tracking_id=two-duplicate>
> >>> o.tracking_id = 'two'
> >>> o.save()
> >>>
> ```
New description:
Reproducible using the test project in https://github.com/farialima
/django-multidbbug . See README.md on how to run it.
The steps are:
- a model with a unique string field (beside the default int PK)
- two DBs in the settings (`default` and `other`)
- two objects in the default DB with PK 1 and 2, and some unique value for
the unique string field
- a object in the other DB (thus, with PK 1) with a different unique
string field value
- in `admin.py`, point the UI to the other database for the model (using
https://docs.djangoproject.com/en/4.0/topics/db/multi-db/#exposing-
multiple-databases-in-django-s-admin-interface)
- in the admin, try modifying the object in the other DB, giving it the
same unique string value as the object with PK 2 in the default database
=> saving fails with error "Parcel with this Tracking id already exists.",
see screenshot.
The underlying issue is clearly that the admin will try to verify in the
default DB that the objects doesn't exist. I think that the admin should
*not* look in the default DB, as I set it up to only use the 'other' DB
for my model...
The issue only occurs in the admin, things are OK when editing the model
objects in code:
{{{
% poetry run ./manage.py shell
(...)
>>> from multidbbugapp.models import Parcel
>>> print(Parcel.objects.all())
<QuerySet [<Parcel: id=1, tracking_id=one>, <Parcel: id=2,
tracking_id=two>]>
>>> print(Parcel.objects.using('other').all())
<QuerySet [<Parcel: id=1, tracking_id=two-duplicate>]>
>>> o = Parcel.objects.using('other').first()
>>> o
<Parcel: id=1, tracking_id=two-duplicate>
>>> o.tracking_id = 'two'
>>> o.save()
>>>
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/33912#comment:1>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/010701828749efee-a6cbe4a9-1d3b-4aff-bce1-34edc765eb8b-000000%40eu-central-1.amazonses.com.