[Django] #26585: Cascade-deletion through generic foreign keys ignores field names
Django
-------------------------------------+-------------------------------------
Reporter: nicklecoder | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.8
contrib.contenttypes | Keywords: genericforeignkey
Severity: Normal | delete
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Create three models:
{{{
from django.db import models
from django.contrib.contenttypes import generic
class Location(models.Model):
address_line1 = models.CharField()
class Account(models.Model):
acct_number = models.CharField()
class Link(models.Model):
account = models.ForeignKey(Account)
linked_object_id = models.PositiveIntegerField()
linked_object_content_type = models.ForeignKey(ContentType)
linked_object =
generic.GenericForeignKey('linked_object_content_type',
'linked_object_id')
}}}
With this setup, deleting a `Location` object will attempt to cascade-
delete any associated `Link` objects. In doing so, Django ignores the
parameters to the `GenericForeignKey` field constructor and instead
expects the content type to be in a field called `content_type` and the
object id in `object_id`. This prevents cascade deletion through generic
foreign keys from working whenever these fields aren't named as expected
or whenever there are multiple generic foreign keys in a model.
--
Ticket URL: <https://code.djangoproject.com/ticket/26585>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: nicklecoder | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.8
contrib.contenttypes |
Keywords: genericforeignkey | Triage Stage:
delete | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_docs: => 0
* needs_tests: => 0
* needs_better_patch: => 0
Old description:
> Create three models:
>
> {{{
> from django.db import models
> from django.contrib.contenttypes import generic
> class Location(models.Model):
> address_line1 = models.CharField()
>
> class Account(models.Model):
> acct_number = models.CharField()
>
> class Link(models.Model):
> account = models.ForeignKey(Account)
> linked_object_id = models.PositiveIntegerField()
> linked_object_content_type = models.ForeignKey(ContentType)
> linked_object =
> generic.GenericForeignKey('linked_object_content_type',
> 'linked_object_id')
> }}}
>
> With this setup, deleting a `Location` object will attempt to cascade-
> delete any associated `Link` objects. In doing so, Django ignores the
> parameters to the `GenericForeignKey` field constructor and instead
> expects the content type to be in a field called `content_type` and the
> object id in `object_id`. This prevents cascade deletion through generic
> foreign keys from working whenever these fields aren't named as expected
> or whenever there are multiple generic foreign keys in a model.
New description:
Create three models:
{{{
from django.db import models
from django.contrib.contenttypes import generic
class Location(models.Model):
address_line1 = models.CharField()
class Account(models.Model):
acct_number = models.CharField()
class Link(models.Model):
account = models.ForeignKey(Account)
linked_object_id = models.PositiveIntegerField()
linked_object_content_type = models.ForeignKey(ContentType)
linked_object =
generic.GenericForeignKey('linked_object_content_type',
'linked_object_id')
}}}
With this setup, deleting a `Location` object will attempt to cascade-
delete any associated `Link` objects. In doing so, Django ignores the
parameters to the `GenericForeignKey` field constructor and instead
expects the content type to be in a field called `content_type` and the
object id in `object_id`. This prevents cascade deletion through generic
foreign keys from working whenever these fields aren't named as expected
or whenever there are multiple generic foreign keys in a model.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26585#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: nicklecoder | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.8
contrib.contenttypes |
Keywords: genericforeignkey | Triage Stage:
delete | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by timgraham):
Could you please verify that the problem exists on master and also include
a test case that reproduces the issue?
--
Ticket URL: <https://code.djangoproject.com/ticket/26585#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: nicklecoder | Owner: nobody
Type: Bug | Status: new
Component: | Version: 1.8
contrib.contenttypes |
Keywords: genericforeignkey | Triage Stage:
delete | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> Create three models:
>
> {{{
> from django.db import models
> from django.contrib.contenttypes import generic
>
> class Location(models.Model):
> address_line1 = models.CharField()
>
> class Account(models.Model):
> acct_number = models.CharField()
>
> class Link(models.Model):
> account = models.ForeignKey(Account)
> linked_object_id = models.PositiveIntegerField()
> linked_object_content_type = models.ForeignKey(ContentType)
> linked_object =
> generic.GenericForeignKey('linked_object_content_type',
> 'linked_object_id')
> }}}
>
> With this setup, deleting a `Location` object will attempt to cascade-
> delete any associated `Link` objects. In doing so, Django ignores the
> parameters to the `GenericForeignKey` field constructor and instead
> expects the content type to be in a field called `content_type` and the
> object id in `object_id`. This prevents cascade deletion through generic
> foreign keys from working whenever these fields aren't named as expected
> or whenever there are multiple generic foreign keys in a model.
New description:
Create three models:
{{{#!python
from django.db import models
from django.contrib.contenttypes import generic
class Location(models.Model):
address_line1 = models.CharField()
class Account(models.Model):
acct_number = models.CharField()
class Link(models.Model):
account = models.ForeignKey(Account)
linked_object_id = models.PositiveIntegerField()
linked_object_content_type = models.ForeignKey(ContentType)
linked_object =
generic.GenericForeignKey('linked_object_content_type',
'linked_object_id')
}}}
With this setup, deleting a `Location` object will attempt to cascade-
delete any associated `Link` objects. In doing so, Django ignores the
parameters to the `GenericForeignKey` field constructor and instead
expects the content type to be in a field called `content_type` and the
object id in `object_id`. This prevents cascade deletion through generic
foreign keys from working whenever these fields aren't named as expected
or whenever there are multiple generic foreign keys in a model.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26585#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: nicklecoder | Owner: nobody
Component: | Version: 1.8
contrib.contenttypes |
Severity: Normal | Resolution: needsinfo
Keywords: genericforeignkey | Triage Stage:
delete | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => needsinfo
Comment:
The report looks a bit suspicious to me.
In order to make `Location` deletion cascades to `Link` a
`GenericRelation` has to be defined on the former which is not the case
here.
Please re-open this ticket if you can provide more details about your
model definitions and an actual traceback.
--
Ticket URL: <https://code.djangoproject.com/ticket/26585#comment:4>