Opened 10 years ago
Closed 17 months ago
#24472 closed New feature (wontfix)
Define internal types explicitly for related fields
Reported by: | Andriy Sokolovskiy | Owned by: | Akash Kumar Sen |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
For related fields internal type is not defined explicitly.
For example, if I want to inherit these fields to add some minor changes, I will need to define internal type manually, because some of backend code is related on internal type of the field.
Old pull request - https://github.com/django/django/pull/4002
We discussed here that is a good idea to have this feature in 1.9
Change History (8)
comment:1 by , 10 years ago
Has patch: | set |
---|
comment:2 by , 10 years ago
I didn't understand the need to add this. Probably some tests are needed to show the use cases.
comment:3 by , 10 years ago
@timgraham, well, it was more suitable for 1.7.x, where we had many places with internal type checks.
At a quick glance in master I found this https://github.com/django/django/blob/a52cd407b86a51e1badf6771e590361e24fd7155/django/db/backends/mysql/schema.py#L61
There may be also places, where are similar checks.
The main goal to give ability for users to not set internal types manually if they need to override one of related fields and give some minor changes.
comment:4 by , 10 years ago
Needs tests: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
I guess this is consistent with the other built-in fields. Could you add regression tests?
comment:5 by , 4 years ago
Status: | new → assigned |
---|
comment:6 by , 4 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:8 by , 17 months ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Triage Stage: | Accepted → Unreviewed |
I don't see a real use case for adding this. Moreover, others do not seem too convinced either and it can cause issue for custom subclasses of related fields. As far as I'm aware, it's not worth changing this long-standing behavior and potential hiccups.
https://github.com/django/django/pull/4296