#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 , 10 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 10 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 , 10 years ago
Resolution: | invalid |
---|---|
Status: | closed → new |
follow-up: 5 comment:4 by , 10 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 , 10 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 thefoobar
app, and the fact that it is defined infoxmask/models.py
does 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_label
to"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
migrations
folder 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_label
as 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.