[Django] #32847: Adjust models.E025 system check for updated field descriptor setting.
Django
-------------------------------------+-------------------------------------
Reporter: Carlton | Owner: nobody
Gibson |
Type: | Status: new
Cleanup/optimization |
Component: Database | Version: dev
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Fix for #30427 and #16176 adjusted the way field descriptors are set when
subclassing abstract models (the descriptor is now always set of child
class)
This left check `models.E025` as perhaps unnecessary, or in need of
replacement/adjustment.
> **models.E025**: The property `<property name>` clashes with a related
field accessor.
The original check made sure you didn't have a clash with a `@property`
named for a foreign key `_id` attribute, such as `fk_id`.
In this case the field descriptor would not have been set, and you'd have
had the property but not the FK.
This is no longer possible, the descriptor will be applied.
([https://github.com/django/django/pull/14508/files#diff-
8d58c4d1755fbc59fdcb4385fb823cbf8e7a9a76350fd4506590e1878328128dR1211-R1216
See the adjustment to make the test pass here.])
* Can we still though detect that such a configuration error occurred,
i.e. that I named a property `*_id` matching an FK accessor?
* Can we then update the system check (or replace it) and adjust/remove
the `test_property_and_related_field_accessor_clash ` test in
`tests/invalid_models_tests/test_models.py`?
Accepting based on
[https://github.com/django/django/pull/14508/files#r648437192 the
discussion on the PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/32847>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
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 Hasan Ramezani):
Hey @Carlton,
I've checked it a little bit and it seems the property replaced by this
[https://github.com/django/django/pull/14508/files#diff-
35c61cb049d39b2e890f12f8c1f9583fb8ca351a8495718b5375a7120f775d05R785
change].
> Can we still though detect that such a configuration error occurred,
i.e. that I named a property *_id matching an FK accessor?
I couldn't find a way to detect.
> Can we then update the system check (or replace it) and adjust/remove
the test_property_and_related_field_accessor_clash test in
tests/invalid_models_tests/test_models.py?
I think we can remove the check and test but I am not sure!
--
Ticket URL: <https://code.djangoproject.com/ticket/32847#comment:1>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
Hi Hasan, thanks for looking.
> I couldn't find a way to detect.
Yes, that's likely. I'll have one more pass at it and see if I can come up
with anything, but if not we can close. (It's a pretty niche config
error...)
--
Ticket URL: <https://code.djangoproject.com/ticket/32847#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Natalia Bidart (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/32847#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Natalia Bidart):
I spent some time reading this ticket and following the referenced PRs and
associated tickets. I think I understand the overall history of the issue,
though I'm somehow lost when it comes to small/specific details. Having
said that, I did try to create a scenario to answer the question:
Can we still though detect that such a configuration error occurred,
i.e. that I named a property *_id matching an FK accessor
and while I don't yet have an answer about ''detect such configuration'',
it's definitely something that in some situations yield to a surprising
result. For example:
{{{
class ModelA(models.Model):
title = models.CharField(max_length=50)
class ModelB(models.Model):
modela = models.ForeignKey(ModelA, on_delete=models.CASCADE)
foo = models.CharField(max_length=3, default='foo')
@property
def modela_id(self):
return 'ERROR'
}}}
Produces models such as any instance of `ModelB` has `modela_id`
effectively being the id of the related `ModelA` instance, instead of
returning the string `ERROR`. As a user, I would appreciate if this
produces a check error or a migration failure or some sort of warning. The
same happens if one would add this field to `ModelB`:
{{{
modela_id = models.IntegerField(default=-100)
}}}
When running `makemigrations`, `No changes detected` is reported and
`modela_id` keeps returning the id of the related `ModelA` instance.
So I would not close this issue, I think at some point we'd want to be
able to produce some check/warning about this clashing.
--
Ticket URL: <https://code.djangoproject.com/ticket/32847#comment:4>