[Django] #28746: New model missing abstract model inherited Meta/Options
Django
-------------------------------------+-------------------------------------
Reporter: JP | Owner: nobody
Navarro |
Type: Bug | Status: new
Component: Database | Version: 1.10
layer (models, ORM) | Keywords: abstract Meta
Severity: Normal | inheritance
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Given:
{{{
class AbstractGlue2Model(models.Model):
ID = models.CharField(primary_key=True, max_length=200)
<stuff>
class Meta:
abstract = True
db_name = 'glue2'
...
class Contact(AbstractGlue2Model):
Detail = models.CharField(max_length=128)
Type = models.CharField(max_length=16)
}}}
A migrate that should create the new Contacts DB objects sees inherited
fields (such as ID), but is missing Meta db_name value:
{{{
(Pdb) pp hints['model']
<class 'Contact'>
(Pdb) pp hints['model']._meta.db_name
*** AttributeError: AttributeError("'Options' object has no attribute
'db_name'",)
(Pdb) pp hints['model']._meta.abstract
False
(Pdb) pp hints['model'].ID
<django.db.models.query_utils.DeferredAttribute object at 0x10f97d6d0>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28746>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by JP Navarro):
Just noticed the relevant migration is missing the db_name:
{{{
options={
'abstract': False,
},
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:1>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by JP Navarro):
This issue is related to [Ticket
#5793|https://code.djangoproject.com/ticket/5793].
I submitted this as a bug because the behavior changed. Prior to 1.10
custom Meta attributes were passed on, as of 1.10.7 they are filtered out.
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:2>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
With your sample code, I get an exception even on Django 1.9 and older:
`TypeError: 'class Meta' got invalid attribute(s): db_name`. If you see a
behavior change, can you
[https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#bisecting-a-regression bisect] to find the commit where it
changed? Even if there's a behavior change, I don't think there's much
obligation to restore the old behavior as it's undocumented and untested.
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:3>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by JP Navarro):
Replying to [comment:3 Tim Graham]:
> With your sample code, I get an exception even on Django 1.9 and older:
`TypeError: 'class Meta' got invalid attribute(s): db_name`. If you see a
behavior change, can you
[https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#bisecting-a-regression bisect] to find the commit where it
changed? Even if there's a behavior change, I don't think there's much
obligation to restore the old behavior as it's undocumented and untested.
Ah, I missed the following code in a custom router where the db_name model
Meta attribute gets used:
import django.db.models.options as options
options.DEFAULT_NAMES = options.DEFAULT_NAMES + ('db_name',)
So, i tracked the problem down to makemigrations which isn't propagating
the 'db_name' attribute to the migration. Does this help narrow down what
change caused this, or do you still need the commit where it changed?
Incidentally, if there is a better way to identify a database where a
model is suppose to exist I'm open to suggestions. The goal is to identify
it with the Model and not somewhere unrelated like a custom router.
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:4>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 1.10
(models, ORM) |
Severity: Normal | Resolution:
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
Yes, it would be helpful if you could bisect. Also, the steps to reproduce
the issue aren't very explicit.
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: JP Navarro | Owner: nobody
Component: Migrations | Version: 1.10
Severity: Normal | Resolution: invalid
Keywords: abstract Meta | Triage Stage:
inheritance | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* component: Database layer (models, ORM) => Migrations
* resolution: => invalid
Comment:
I bisected the behavior change to
50931dfa5310d5ae1c6e2852d05bf1e86700827f. It's seemingly unrelated but I
guess the issue may be related to import changes in that patch and timing
in which the `options.DEFAULT_NAMES` monkeypatch is running. Feel free to
reopen if you do further investigation and find that Django is at fault.
--
Ticket URL: <https://code.djangoproject.com/ticket/28746#comment:6>