#33272: Non-installed model error isn't raised if the module is in the 
submodule of
an installed app
-------------------------------------+-------------------------------------
     Reporter:  David Seddon         |                    Owner:  nobody
         Type:  Uncategorized        |                   Status:  closed
    Component:  Database layer       |                  Version:  3.2
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  invalid
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by David Seddon):

 Thanks for your reply and sorry if I haven't explained the issue well
 enough. I'm going to give it another try.

 (Context: I've been a full time Django dev for over a decade so I'm not
 coming to this as a newbie.)

 My argument is that Django has an inconsistent picture of what models
 belong to an app.

 In the above example, let's imagine we run `manage.py makemigrations foo`.
 Django will not pick up anything from `foo/bar/models.py`, because they
 are not imported from `foo/models.py`. In that version of things, Django
 (rightly I think) does not view those models as part of the app.

 However, if, elsewhere, we import a model from `foo/bar/models.py`, the
 
[https://github.com/django/django/blob/ca9872905559026af82000e46cde6f7dedc897b6/django/apps/registry.py#L250
 get_containing_app_config] method will treat the model as in `foo`
 application, even though it wasn't (and shouldn't have been) registered.

 In my opinion the `Model class x doesn't declare an explicit app_label...`
 exception should be raised whenever a model is imported that wasn't
 registered in the course of Django bootstrapping. It shouldn't matter that
 that module happens to be in a subpackage of an installed app - that seems
 to me to be too much of a blunt instrument.

 This behaviour causes us problems in our Django application, because we
 have apps that are only sometimes installed, that are submodules of other
 installed apps.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/33272#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0a81fb7eed162b1a6e9d1137199b5087%40djangoproject.com.

Reply via email to