Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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 Shai Berger, 10 years ago

Resolution: invalid
Status: newclosed

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, use db_table.

The next piece is that apps without a migrations folder are considered "unmigrated" apps, and have the same behavior as old syncdb -- 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.

comment:2 by FoxMaSk, 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 FoxMaSk, 10 years ago

Resolution: invalid
Status: closednew

comment:4 by Shai Berger, 10 years ago

Resolution: invalid
Status: newclosed

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.

in reply to:  4 comment:5 by FoxMaSk, 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 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.

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.

Note: See TracTickets for help on using tickets.
Back to Top