However, when I use 'python manage.py makemigrations',
it does not find any tables/changes and no migrations are created.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_docs: => 0
Comment:
Thanks for reporting this issue.
Could you try reproducing against the master branch and provide and
provide a sample of your <appname>.models.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:1>
Comment (by loic84):
roughdesignapps@ could you try with `python --Wall`? Are you using an
`AppConfig` with a custom `label` by any chance?
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:2>
Comment (by roughdesignapps@…):
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}}}.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:3>
Comment (by loic84):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:4>
Comment (by roughdesignapps@…):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:5>
Comment (by loic84):
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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:6>
* version: 1.7-alpha-2 => master
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22415#comment:7>