sqlall etc. don't work on models within a package

This may be a silly question, but does your __init__.py specify which files are part of the module?

Should it be necessary to have all the classes in the package namespace? I don't believe so. Half the reason for trying to create separate modules was so I'd have separate namespaces to group related models.

But to answer your question: before posting the ticket, I'd tried both:

# other models get missed models/init.py # core models models/other.py # other models

and

# all models get missed models/init.py # contains 'from app.models.core import A, B' and 'from app.models.other import C, D' models/core.py # core models models/other.py # other models

With the latter, manage.py sqlall didn't output sql for any models.

Sorry, tried to use the wrong markup for code blocks (too-many-wiki-syntaxes syndrome). Those should have been:

# other models get missed
models/__init__.py  # core models
models/other.py     # other models

and

# all models get missed
models/__init__.py  # contains 'from app.models.core import A, B' and 'from app.models.other import C, D'
models/core.py      # other models
models/other.py     # other models

This is kind of a wart, but it is possible to work around: put an app_label attribute on the inner Meta class in each of your models. The value of this attribute should be the dotted Python path to the application directory. So if your directory structure looks like

project/
   application/
      models/
         __init__.py
         mymodels1.py
         mymodels2.py
         ...

Then app_label on each model would be 'project.application'.

Fixing this in a better way is the topic of #1821.

That workaround is no good for several reasons, the most obvious being that it doesn't work at all; manage.py still fails to see the other models--although the models are imported into models/__init__.py, and each models has class Meta: app_label='myproject.myapp' (the names I'm using in an isolated test project).

But more importantly, the workaround isn't suitable because:

• The application I'm developing is intended to be used in several different projects, so it must be independent of the project name
• Even if it did work, it still requires all the models to be in a flat namespace, which is not desirable.

I can't see the connection between this problem and #1821 -- can you enlighten me?

The connection with #1821 is that it provides a way to specify once what the application label is. That is the hard bit here: we need to know the app name in a number of places.

After poring over db/models/loading.py and db/models/base.py, I finally found that app_label should have been myapp, not myproject.myapp; then it works as advertised.

It's not a perfect solution, but it's close enough for me right now. Cheers!

Using app_label on each model is a workable solution. There's not enough of a problem here to be worth chasing up.