#24059 closed Bug (invalid)
app_label not handled when set to the same project name in all the django app
| Reported by: | FoxMaSk | Owned by: | nobody |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Here is the process to follow :
(django-bugs)foxmask@foxmask:~/Django-VirtualEnv/django-bugs/ django-admin startproject foobar (django-bugs)foxmask@foxmask:~/Django-VirtualEnv/django-bugs/ django-admin startapp foxmask
in the models of foobar project :
# -*- coding: utf-8 -*- from django.db import models class Foobarmodel(models.Model): tag = models.CharField(max_length=80, blank=True) url = models.URLField(max_length=255) title = models.CharField(max_length=80, blank=True) class Meta: app_label = 'foobar'
in the models of foxmask app :
# -*- coding: utf-8 -*- from django.db import models from foobar.models import Foobarmodel class Pocket(Foobarmodel): content = models.CharField(max_length=80, blank=True) class Meta: app_label = 'foobar'
in the settings.py of foobar project of course :
# Application definition INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'foobar', 'foxmask', )
then
(django-bugs)foxmask@foxmask:~/Django-VirtualEnv/django-bugs/foobar$ ./manage.py migrate
Operations to perform:
Synchronize unmigrated apps: foobar
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Creating table foobar_foobarmodel
Creating table foobar_pocket
Installing custom SQL...
Installing indexes...
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying sessions.0001_initial... OK
to check, i do it again
(django-bugs)foxmask@foxmask:~/Django-VirtualEnv/django-bugs/foobar$ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: foobar Apply all migrations: admin, contenttypes, auth, sessions Synchronizing apps without migrations: Creating tables... Installing custom SQL... Installing indexes... Running migrations: No migrations to apply.
I modify the models of foxmask to :
# -*- coding: utf-8 -*- from django.db import models from foobar.models import Foobarmodel class Pocket(Foobarmodel): content = models.CharField(max_length=800, blank=True) class Meta: app_label = 'foobar'
then :
(django-bugs)foxmask@foxmask:~/Django-VirtualEnv/django-bugs/foobar$ ./manage.py makemigrations No changes detected
The fact is that if my app_label in the foxmask app is set to something else to "foobar" ; everything goes fine
But I need to set it to foobar in all the django app I provide to maintain consistency in the name of the table that django generates
Change History (5)
comment:1 by , 11 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 11 years ago
I did startapp foxmask which created the migrations folder in foxmask app, and i still did makemigrations as you can read in my last piece of log.
So i dont understand.
comment:3 by , 11 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → new |
follow-up: 5 comment:4 by , 11 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
In the second paragraph in my previous comment I explained that once you set the model's app_label, Django treats it as if it belonged to the other app. Again: Your model with app_label = 'foobar' belongs to the foobar app, and the fact that it is defined in foxmask/models.py does not matter.
If this is still not clear to you, as I said, please use Django's support channels.
comment:5 by , 11 years ago
Replying to shaib:
In the second paragraph in my previous comment I explained that once you set the model's app_label, Django treats it as if it belonged to the other app. Again: Your model with
app_label = 'foobar'belongs to thefoobarapp, and the fact that it is defined infoxmask/models.pydoes not matter.
If this is still not clear to you, as I said, please use Django's support channels.
I tested with db_table and it's ok. Now I have another problem (OperationalError: no such table: xxx) , but with this current test case, the problem I have in production, is not here. So thanks at least for showing the path to the solution.
I suspect what you see is the documented behavior, although it may not seem that way.
The most unintuitive point, probably, is that by setting the model's
app_labelto"foobar", you have effectively placed it in the "foobar" app, even though the model is defined in foxmask/models.py. If you just want to control the database table name, usedb_table.The next piece is that apps without a
migrationsfolder are considered "unmigrated" apps, and have the same behavior as oldsyncdb-- only new models are added, changes in existing models are not detected; and the project app -- which typically has no models -- does not, by default, have migrations either.So, by setting the
app_labelas you have, you've put your models in an unmigrated app.You can add migrations to the project app by running
./manage.py makemigrations foobar.If you still feel there is a problem with Django's behavior here, please ask about it on the mailing list -- see UsingTheMailingList.