Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#22415 closed Bug (needsinfo)

Migrate problems concerning foreignkeys to self

Reported by: roughdesignapps@… Owned by: nobody
Component: Migrations Version: dev
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

Running 'python manage.py makemigrations <appname>' creates migrations for the app,

However, when I use 'python manage.py makemigrations',
it does not find any tables/changes and no migrations are created.

Change History (7)

comment:1 by Simon Charette, 10 years ago

Resolution: needsinfo
Status: newclosed

Thanks for reporting this issue.

Could you try reproducing against the master branch and provide and provide a sample of your <appname>.models.

comment:2 by loic84, 10 years ago

roughdesignapps@ could you try with python --Wall? Are you using an AppConfig with a custom label by any chance?

comment:3 by roughdesignapps@…, 10 years ago

I am using a models folder with init.py importing the other .py files and

class Meta:
    app_label = 'foodapp'

in the models.

I will be able to try reproducing against the master branch in an hour or so.

I'm sorry, I actually have no idea what python --Wall is, Google does not help me there and my command prompt won't execute python --Wall.

comment:4 by loic84, 10 years ago

Sorry I've added an extra hyphen, it should be python -Wall, it tells python to print all warnings, most notably PendingDeprecationWarning which are normally silenced.

Can you double check that the package name of your app is foodapp? Also you may want to try commenting out the app_label = 'foodapp' line, if I remember well a recent commit made it unnecessary for submodules of the models package.

comment:5 by roughdesignapps@…, 10 years ago

I update django to master and removed app_label.
It still does not find any changes.

A model sample:

class LegalDocumentSet(models.Model):

    objects = DocumentManager()
    country = models.ForeignKey(Country)
    country.help_text = "The country for which the documents are."
    published = models.BooleanField(default=False)
    published.help_text = """If the document is not published,
        it will not be shown on the website."""
    imprint = models.TextField()
    terms_and_conditions = models.TextField()
    cancellation_policy = models.TextField()

    def __str__(self):
        "@rtype:   str"
        return str(self.country)

With DocumentManager being a simple subclass of models.Manager with only one method added.

comment:6 by loic84, 10 years ago

roughdesignapps@ when you use python manage.py makemigrations <appname> everything works as excepted?

python manage.py makemigrations deliberately ignore any app that doesn't have a migrations directory, this is because using the migration framework is optional. To start using migrations with a given app, you indeed need to use python manage.py makemigrations <appname>, or you can manually create an empty migrations directory in your app before running python manage.py makemigrations.

comment:7 by roughdesignapps@…, 10 years ago

Version: 1.7-alpha-2master

Well, loic84, that makes sense the way you tell it, but then there is another problem when initiating a database.

When I have an empty database and run python manage.py makemigrations <appname>,I get an error about django_content_types not being present.

What I tried in that situation is first syncdb to create all the tables, then makemigrations.<appname> to create migrations per app, and then run migrate to have the migrations updated.

Problem with THAT is that I have a model with a foreignkey to self, for which makemigrations always creates 2 migrations:
One to initiate the table with all fields except the foreignkey
and a second migration which only adds the foreignkey field.

syncdb already created all the tables and when I run migrate, so the migrations where tables are created are ignored.
However, it tries to apply the migration which adds the foreignkey to the model, which then gives an error because the field already exists.

For now I worked around that by transferring the content of the add-foreignkey-migration to the migration where the table is created.

So, the problem is EITHER that makemigrations creates 2 migrations as initial migrations
OR that migrate does not ignore adding a field if it does already exist.

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