[Django] #28824: Allow different Foreign Keys to share same underlying DB column
Django
-------------------------------------+-------------------------------------
Reporter: klass- | Owner: nobody
ivan |
Type: New | Status: new
feature |
Component: Database | Version: 1.11
layer (models, ORM) | Keywords: foreigh key,
Severity: Normal | db_column,
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
{{{
class A(Model):
uid = CharField(unique=True)
# other fields
class B(Model):
uid = CharField(unique=True)
# other fields
class C(Model):
# other fields
uid = CharField(unique=False)
a = ForeignKey(to=A, to_field='uid', db_column='uid', null=True)
b = ForeignKey(to=B, to_field='uid', db_column='uid', null=True)
}}}
Gives an error:
{{{
Field 'b' has column name 'uid' that is used by another field.
HINT: Specify a 'db_column' for the field.
}}}
However, ForeignKey field is a ORM relation based on underlying column
anyway.
I think it won't break anything if we allow different foreign keys to
share same underlying column.
This adds more flexibility and will allow better django "on-boarding"
process for legacy projects.
It will be also useful when A or B is proxy model - so we can get
different proxy objects by different foreign keys referencing same DB row.
Another example can be found here:
[https://stackoverflow.com/questions/36911804/django-use-same-column-for-
two-foreign-keys]
--
Ticket URL: <https://code.djangoproject.com/ticket/28824>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
Keywords: foreigh key, | Triage Stage:
db_column, | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by klass-ivan):
If skip `_check_column_name_clashes` in models.base, the next issue will
be in `_do_insert` - DB error that "Column '<column_name>' specified
twice"
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
Keywords: foreigh key, | Triage Stage:
db_column, | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Josh Smeaton):
I'm struggling to see where the value for this change would be, and how
common a situation this really is. I think the benefit of supporting this
would be outweighed by users that are incorrectly duplicating keys on
their models with copy/paste and running into legitimate issues.
Further, I believe you can (probably) get similar behaviour working if you
reverse the location of your keys, and switch to using OneToOne. I haven't
tested this myself, but I think this would work:
{{{
class A(Model):
uid = CharField(unique=True)
c = OneToOneField(to=C, to_field='uid', db_column='uid', null=True)
class B(Model):
uid = CharField(unique=True)
c = OneToOneField(to=C, to_field='uid', db_column='uid', null=True)
class C(Model):
# other fields
uid = CharField(unique=False)
c = get_c(..)
c.a # fine
c.b # fine
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:2>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.11
(models, ORM) |
Keywords: foreigh key, | Triage Stage:
db_column, | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:3>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution:
db_column, | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: wontfix =>
Comment:
Reopening because I think there is a valid case for this, referenced in my
previous comment.
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:5>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.11
(models, ORM) |
Keywords: foreigh key, | Triage Stage:
db_column, | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Matt, please
[https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
tickets/#closing-tickets follow triaging guidelines with regards to
wontfix tickets.]
Moreover this comment is still valid, even with a use case:
> I'm struggling to see where the value for this change would be, and how
common a situation this really is. I think the benefit of supporting this
would be outweighed by users that are incorrectly duplicating keys on
their models with copy/paste and running into legitimate issues.
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:6>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: foreigh key, | Triage Stage:
db_column, | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by James Lin):
This issue becomes more apparent when creating models on top of existing
database just to read from.
--
Ticket URL: <https://code.djangoproject.com/ticket/28824#comment:7>