Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#33510 closed Bug (invalid)

dumpdata misses models subclassed from other non-abstract models

Reported by: Robin Harms Oredsson Owned by: nobody
Component: Core (Management commands) Version: 3.2
Severity: Normal Keywords: dumpdata
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Essentially the same issue that was fixed in Django 2 has resurfaced in 3 so I'll only write a short description.

class Person(models.Model):
     some_field...
    ...


class Doctor(Person):
     doctor_field...
     ...


my_doctor = Doctor.objects.create(...)

Running manage dumpdata will cause the export to be broken. The "my_doctor" instance will be exported without the pointer to the person-object it will models will be within the export, but without the linking pointer value. (Probably called something like person_ptr) However if --natural-primary is included, the key will be there.

However, regardless of method the needed linked data within the person table is omitted, so running import data on a site with subclassed models like this will never work.

This bug seems to be present in 3.0 and onward.

Change History (2)

comment:1 by Mariusz Felisiak, 3 years ago

Resolution: invalid
Status: newclosed
Summary: dumpdata command misses models sublcassed from other non-abstract modelsdumpdata misses models subclassed from other non-abstract models

Thanks for the report.

However, regardless of method the needed linked data within the person table is omitted, so running import data on a site with subclassed models like this will never work.

Have you tried to import dumped data? It works for me in both cases, i.e. with and without using --natural-primary. person_ptr is unnecessary because it's a OneToOneField() which is also a Doctor's primary key, see docs.

comment:2 by Robin Harms Oredsson, 3 years ago

Hi, sorry about this. You're right - the reason I have this problem is that the superclass has a custom manager that causes polymorphic behaviour, so the 1-1 relation becomes corrupt. So not a problem with Django.

I thought those custom managers were disabled during exporting though?

Note: See TracTickets for help on using tickets.
Back to Top