blocks|key|88920|text|重命名旧迁移文件夹后是否使用了schemamigration+my_app+--initial？试试看。也许行得通。如果不是，请尝试重新创建数据库并创建syncdb%2Bmigrate。对我来说很管用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|88921|entityMap^0|F|W|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Did u use <code>schemamigration my_app --initial</code> after renaming old migration folder? Try it. Might work. If not - try to recreate the database and make syncdb+migrate. It worked for me...

blocks|key|4595149|text|好吧，看起来我遗漏了一个明显的步骤，但发布这篇文章是为了防止其他人也这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595150|当升级到1.7时，我的模型变成了非托管(managed+=+False)+--我以前用它们作为True，但它似乎被恢复了。|offset|length|style|CODE|4595151|删除这一行(默认为True)，然后运行makemigrations立即生成一个迁移模块，现在它可以工作了。makemigrations不能在非托管表上工作(这在事后是显而易见的)|4595152|entityMap^0|0|K|F|1B|4|0|J|E|1H|E|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@$D|S|E|T|F|G]|$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|K|$]]

Ok, looks like I missed an obvious step, but posting this in case anyone else does the same.

When upgrading to 1.7, my models became unmanaged (<code>managed = False</code>) - I had them as <code>True</code> before but seems it got reverted.

Removing that line (To default to True) and then running <code>makemigrations</code> immediately made a migration module and now it's working. <code>makemigrations</code> will not work on unmanaged tables (Which is obvious in hindsight)

blocks|key|88944|text|我也遇到了同样的问题，不得不运行两次makemigrations，以及各种奇怪的行为。事实证明，问题的根源是我在模型中使用了一个函数来设置默认日期，所以每次我运行makemigrations时，迁移都会检测到更改。这个问题的答案让我走上了正确的道路：Avoid+makemigrations+to+re-create+date+field|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|88945|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/27330877/avoid-makemigrations-to-re-create-date-field/27331101#27331101^0|3H|18|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I had the same problem with having to run makemigrations twice and all sorts of strange behaviour. It turned out the root of the problem was that I was using a function to set default dates in my models so migrations was detecting a change every time I ran makemigrations. The answer to this question put me on the right track: <a href="https://stackoverflow.com/questions/27330877/avoid-makemigrations-to-re-create-date-field/27331101#27331101">Avoid makemigrations to re-create date field</a>

blocks|key|4595199|text|也许这会对某人有帮助。我在使用一个嵌套的应用程序。project.appname和我实际上在INSTALLED_APPS中有项目和project.appname。从INSTALLED_APPS中删除项目可以检测到更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595200|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Maybe this will help someone. I was using a nested app. project.appname and I actually had project and project.appname in INSTALLED_APPS. Removing project from INSTALLED_APPS allowed the changes to be detected.

blocks|key|4595262|text|您需要检查INSTALLED_APPS列表中的settings.py，并确保所有具有型号的应用程序都列在其中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4595263|在项目文件夹中运行makemigrations意味着它将更新与项目的settings.py中包含的所有应用程序相关的所有表。一旦你包含了它，makemigrations将自动包含该应用程序(这节省了大量的工作，所以你不必为你的项目/站点中的每个应用程序运行makemigrations+app_name+)。|4595264|entityMap^0|5|E|N|B|0|9|E|Y|B|1Y|E|3K|N|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

You want to check the <code>settings.py</code> in the <code>INSTALLED_APPS</code> list and make sure all the apps with models are listed in there.

Running <code>makemigrations</code> in the project folder means it will look to update all the tables related to all the apps included in <code>settings.py</code> for the project. Once you include it, <code>makemigrations</code> will automatically include the app (this saves a lot of work so you don't have to run <code>makemigrations app_name</code> for every app in your project/site).

blocks|key|89061|text|以防你有一个特定的字段没有被makemigrations识别:如果你有一个同名的属性，请检查两次。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|89062|示例：|89063|field+=+django.db.models.CharField(max_length=10,+default+=+'',+blank=True,+null=True)

#+...+later

@property
def+field(self):
++++pass|code-block|syntax|javascript|89064|该属性将“覆盖”字段定义，因此更改不会被makemigrations标识|offset|length|style|CODE|89065|entityMap^0|0|0|0|K|E|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@$K|U|L|V|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Just in case you have a specific field that does not get identified by makemigrations: check twice if you have a property with the same name.

example:

<pre><code>field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
 pass
</code></pre>

the property will "overwrite" the field definition so changes will not get identified by <code>makemigrations</code>

blocks|key|89108|text|这是一个愚蠢的错误，但是在model类的字段声明行的末尾加上一个额外的逗号，会使这一行没有任何效果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|89109|在复制粘贴def时会发生这种情况。迁移本身被定义为一个数组。|89110|尽管这可能会对某些人有所帮助:-)|89111|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

This is kind of a stupid mistake to make, but having an extra comma at the end of the field declaration line in the model class, makes the line have no effect.

It happens when you copy paste the def. from the migration, which itself is defined as an array.

Though maybe this would help someone :-)

blocks|key|4595355|text|确保您的模型不是abstract。我实际上犯了这个错误，花了一段时间，所以我想我应该把它贴出来。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4595356|entityMap^0|8|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Make sure your model is not <code>abstract</code>. I actually made that mistake and it took a while, so I thought I'd post it.

blocks|key|4595436|text|我最近将Django从1.6升级到1.8，几乎没有应用程序和迁移。我使用south和schemamigrations在Django+1.6中创建迁移，Django+1.8中删除了它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4595437|当我在升级后添加新型号时，makemigrations命令没有检测到任何更改。然后我尝试了@drojf+(第一个答案)建议的解决方案，它工作得很好，但无法应用假初始迁移(python+manage.py+--fake-initial)。我这样做是因为我的表(旧表)已经创建好了。|4595438|最后，这个方法对我起作用了，从models.py中删除了新的模型(或模型变化)，然后不得不删除(或为了安全起见重命名)所有应用程序的迁移文件夹，并对所有应用程序运行python+manage.py+makemigrations，然后执行python+manage.py+migrate+--fake-initial。这就像一个护身符。一旦为所有应用程序创建了初始迁移，并伪造了初始迁移，然后添加了新模型，并遵循了makemigrations的常规流程并在该应用程序上进行了迁移。现在检测到了变化，一切都进行得很好。|4595439|我只是想在这里分享它，如果有人遇到同样的问题(在他们的应用程序中使用南方的schemamigrations+)，这可能会对他们有所帮助:)|4595440|entityMap^0|16|G|0|D|E|2D|V|0|2H|9|3A|13|5Q|E|0|11|G|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|L|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|M|$]]

I recently upgraded Django from 1.6 to 1.8 and had few apps and migrations for them. I used south and <code>schemamigrations</code> for creating migrations in Django 1.6, which is dropped in Django 1.8. 

When I added new models after upgrade, the <code>makemigrations</code> command wasn't detecting any changes. And then I tried the solution suggested by @drojf (1st answer), it worked fine, but failed to apply fake initial migration (<code>python manage.py --fake-initial</code>). I was doing this as my tables (old tables) were already created.

Finally this worked for me, removed new models (or model changes) from models.py and then had to delete (or rename for safety backup) migrations folder of all apps and run python <code>manage.py</code> makemigrations for all apps, then did <code>python manage.py migrate --fake-initial</code>. This worked like a charm. Once initial migration is created for all apps and fake initial migrated, then added new models and followed regular process of <code>makemigrations</code> and migrate on that app. The changes were detected now and everything went fine.

I just thought of sharing it here, if someone faces same problem (having <code>schemamigrations</code> of south for their apps), it might help them :)

blocks|key|89235|text|也许我来得太晚了，但你有没有尝试在你的应用程序中包含一个包含__init__.py文件的migrations文件夹？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|89236|entityMap^0|U|B|18|A|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Maybe I am too late but did you try to have a <code>migrations</code> folder in your app with a <code>__init__.py</code> file in it?

blocks|key|4595534|text|./manage+makemigrations
./manage+migrate|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|4595535|迁移跟踪数据库的变化，因此，如果您从非托管更改为托管，则需要确保您的数据库表与您正在处理的模型相关的最新。|unstyled|4595536|如果您仍然处于开发模式，我个人决定删除我的集成开发环境中的迁移文件以及与我的模型相关的django_migrations表中的迁移文件，并重新运行上面的命令。|4595537|请记住:如果您的迁移在集成开发环境中以_001结束，而在数据库中以_003结束。Django只会看到你的迁移是否以_004结尾，有什么要更新的。|4595538|这2个(代码和数据库迁移)是链接在一起的，并且协同工作。|4595539|祝你编码愉快。|4595540|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|R|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|F|7|W|8|@]|9|@]|A|$]]]|P|$]]

<pre><code>./manage makemigrations
./manage migrate
</code></pre>

Migrations track changes to DB so if youre changing from unmanaged to managed, you'll need to make sure that youre database table is up to date relating to the Model you're dealing with.

If you are still in dev mode, I personally decided to delete the migration files in my IDE as well as in the django_migrations table relating to my Model and rerun the above command.

REMEMBER: if you have a migration that ends with _001 in your IDE &amp; _003 in your database. Django will only see if you have a migration ending with _004 for anything to update.

The 2 (code &amp; db migrations) are linked and work in tandem.

Happy coding.

blocks|key|4595582|text|添加我的2c，因为这些解决方案对我都不起作用，但这个确实起作用了……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595583|我刚刚运行了manage.py+squashmigrations并删除了旧的迁移(包括django.migrations数据库表中的文件和行)。|offset|length|style|CODE|4595584|这在最后一个迁移文件中留下了类似这样的一行：|4595585|replaces+=+[(b'my_app',+'0006_auto_20170713_1735'),+(b'my_app',+'0007_auto_20170713_2003'),+(b'my_app',+'0008_auto_20170713_2004')]|code-block|syntax|javascript|4595586|这显然使Django感到困惑，并导致了奇怪的行为:运行manage.py+makemigrations+my_app将重新创建初始迁移，就好像不存在一样。删除replaces...行解决了这个问题！|4595587|entityMap^0|0|6|Q|0|0|0|R|V|27|B|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|X|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|Y|8|@$D|Z|E|10|F|G]|$D|11|E|12|F|G]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|R|$]]

Adding my 2c, since none of these solutions worked for me, but this did...

I had just run <code>manage.py squashmigrations</code> and removed the old migrations (both the files and lines in the the django.migrations database table).

This left a line like this in the last migration file:

<pre><code>replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]
</code></pre>

This apparently confused Django and caused weird behavior: running <code>manage.py makemigrations my_app</code> would recreate the initial migration as if none existed. Removing the <code>replaces...</code> line fixed the problem!

blocks|key|89343|text|您可能需要使用以下命令伪造初始迁移|type|unstyled|depth|inlineStyleRanges|entityRanges|data|89344|python+manage.py+migrate+--fake-initial|code-block|syntax|javascript|89345|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You may need to fake the initial migrations using the command below

<pre><code>python manage.py migrate --fake-initial
</code></pre>

blocks|key|4595654|text|首先，这个解决方案适用于那些在heroku服务器上部署时遇到相同问题的人，我也遇到了同样的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595655|要进行部署，有一个强制步骤，即在settings.py文件中添加django_heroku.settings(locals())。|4595656|更改:当我将上面的代码行更改为django_heroku.settings(locals()，databases=False)时，它可以完美地工作。|4595657|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

First this solution is applicable to those who are facing the same issue during deployment on heroku server, I was facing same issue.

To deploy, there is a mandatory step which is to add django_heroku.settings(locals()) in settings.py file.

Changes:
When I changed the above line to django_heroku.settings(locals(), databases=False), it worked flawlessly.

blocks|key|4595672|text|accounts\migrations\0001_initial.py+-创建模型客户-创建模型标签-创建模型产品-创建模型订单|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595673|注意:这里的"accounts“是我的应用程序名称|4595674|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

python manage.py makemigrations accounts
Migrations for 'accounts':
 accounts\migrations\0001_initial.py
 - Create model Customer
 - Create model Tag
 - Create model Product
 - Create model Order

Note: here "accounts" is my app name

blocks|key|4595687|text|我遇到过这个问题，命令|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595688|python+manage.py+makemigrations|code-block|syntax|javascript|4595689|一旦我保存了我对文件所做的更改，它就会与我一起工作。|4595690|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I have encountered this issue, the command
<pre><code>python manage.py makemigrations
</code></pre>
worked with me once I saved the changes that I made on the files.

blocks|key|4595751|text|原因之一可能是你没有在admin.py文件中注册你的模型。首先在admin.py文件中注册模型，然后进行迁移。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4595752|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

One of the cause may be You didn't register your models in admin.py file .
First register your models in admin.py file then do the migrations.

blocks|key|4595787|text|我错误地从项目目录中删除了migrations的文件夹。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4595788|解决方案是在migrations文件夹中创建__init__.py文件，然后|4595789|python+manage.py+makemigrations
python+manage.py+migrate|code-block|syntax|javascript|4595790|entityMap^0|D|A|0|6|A|M|B|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|W|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|N|$]]

I had mistakely deleted folder of <code>migrations</code> from my project directory.
Solution is to create <code>__init__.py</code> file in the <code>migrations</code> folder, and then,
<pre><code>python manage.py makemigrations
python manage.py migrate
</code></pre>

As the title says, I can't seem to get migrations working.

The app was originally under 1.6, so I understand that migrations won't be there initially, and indeed if I run <code>python manage.py migrate</code> I get:

<pre><code>Operations to perform:
 Synchronize unmigrated apps: myapp
 Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
 Creating tables...
 Installing custom SQL...
 Installing indexes...
Running migrations:
 No migrations to apply.
</code></pre>

If I make a change to any models in <code>myapp</code>, it still says unmigrated, as expected.

But if I run <code>python manage.py makemigrations myapp</code> I get:

<pre><code>No changes detected in app 'myapp'
</code></pre>

Doesn't seem to matter what or how I run the command, it's never detecting the app as having changes, nor is it adding any migration files to the app.

Is there any way to force an app onto migrations and essentially say "This is my base to work with" or anything? Or am I missing something?

My database is a PostgreSQL one if that helps at all.

Django 1.7 - makemigrations not detecting changes

集成开发环境

SQL数据库

PostgreSQL

数据库

服务器

Django

正如标题所说，我似乎无法让迁移正常工作。这个应用程序最初是1.6以下的，所以我知道迁移最初不会在那里，实际上，如果我运行python manage.py migrate，我会得到：Operations to perform:  Synchronize unmigrated apps: myapp  Apply all ...

问Django 1.7 -未检测到变化的makemigrations
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Django 1.7 -未检测到变化的makemigrationsEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Django 1.7 -未检测到变化的makemigrations
EN