#24539: Attempt to create object with repeated value on a custom PK raises
IntegrityError on wrong field
-------------------------------+------------------------------------
Reporter: emyller | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by fero):
I debugged it for a while during the Django sprint at pycon6 Italy and it
seems to be quite ''a [https://en.wikipedia.org/wiki/Pandora%27s_box
Pandora's box]''.
I reviewed it with @apollo13 and here are the results, for a bug that
can't be solved today.
In our opinion there are some bugs actually:
1. regarding to the ORM low-level exception, the story is: '''''when a
user add a new instance from the Admin UI, he expects to INSERT a new
object''''' here is a candidate patch:
{{{
--- a/django/contrib/admin/options.py
+++ b/django/contrib/admin/options.py
@@ -969,7 +969,11 @@ class ModelAdmin(BaseModelAdmin):
"""
Given a model instance save it to the database.
"""
- obj.save()
+ if not change:
+ obj.save(force_insert=True)
+ else:
+ obj.save()
+
def delete_model(self, request, obj):
"""
}}}
in this way the ORM performs an "INSERT" and raises the right
`IntegrityError` exception '''UNIQUE constraint failed:
base_product.reference''' (provided that you use python3 or you have
applied some fixes/patches from #23643)
2. regarding to the UX, the story is: '''''when a user input some wrong
values in a form, he expects to get a `ValidationError` with pink-rabbits
decorations'''''. I digged in this part with the help of @apollo13 and I
noticed that the overridden primary_key field is correctly validated with
the following "adjustment" ;) :
{{{
--- a/django/forms/models.py
+++ b/django/forms/models.py
@@ -433,7 +433,7 @@ class BaseModelForm(BaseForm):
self.instance = construct_instance(self, self.instance,
opts.fields, construct_instance_exclude)
try:
- self.instance.full_clean(exclude=exclude,
validate_unique=False)
+ self.instance.full_clean(exclude=exclude,
validate_unique=True)
except ValidationError as e:
self._update_errors(e)
}}}
Agreeing with @apollo13 this topic requires further discussion. So I leave
it up to you dear core developers ;) This regards to `ModelForm` though
and so has wider impact than the only admin interface (new ticket needed?)
3. after that, the update of a primary key value has another mess to deal
with: '''''when a user update the value, he expects to just update that
value ;)'''''.
The following cases could happen when value switches from `xxx` to `yyy`:
a. one record with `yyy` already exists -> `ValidationError` should be
raised and this could happen after fixing the `validate_unique` above
b. one record with `yyy` does not exists -> the value is updated.
Currently when the user update the value to `yyy`, the ORM performs
`UPDATE table SET k='yyy' WHERE k='yyy'` instead of `UPDATE table SET
k='yyy' WHERE k='xxx'`
That's my end of the sprint, it has been a good day, thanks Django team!
--
Ticket URL: <https://code.djangoproject.com/ticket/24539#comment:7>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.5241c150d7352d69926ca501fd0d1f9a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
