标签归档:django-1.7

如何从Django 1.7的初始迁移迁移回去?

问题:如何从Django 1.7的初始迁移迁移回去?

我用一些模型创建了一个新的应用程序,现在我发现一些模型没有经过深思熟虑。由于我尚未提交代码,因此明智的做法是将数据库迁移到最后的良好状态,并使用更好的模型重新进行迁移。在这种情况下,最后的良好状态是新应用程序不存在的数据库。

如何从Django 1.7的初始迁移迁移回去?

South一个可以这样做:

python manage.py migrate <app> zero

<app>将从迁移历史记录中清除并删除的所有表<app>

如何在Django 1.7迁移中做到这一点?

I created a new app with some models and now I noticed that some of the models are poorly thought out. As I haven’t committed the code the sensible thing would be to migrate the database to last good state and redo the migration with better models. In this case the last good state is database where the new app doesn’t exist.

How can I migrate back from initial migration in Django 1.7?

In South one could do:

python manage.py migrate <app> zero

Which would clear <app> from migration history and drop all tables of <app>.

How to do this with Django 1.7 migrations?


回答 0

您也可以使用Django 1.7+进行相同操作:

python manage.py migrate <app> zero

<app>将从迁移历史记录中清除,并删除所有的表<app>

有关更多信息,请参见django文档

You can do the same with Django 1.7+ also:

python manage.py migrate <app> zero

This clears <app> from migration history and drops all tables of <app>

See django docs for more info.


回答 1

您还可以使用版本号:

python manage.py migrate <app> 0002

来源:https : //docs.djangoproject.com/en/1.7/ref/django-admin/#django-admin-migrate

you can also use the version number:

python manage.py migrate <app> 0002

Source: https://docs.djangoproject.com/en/1.7/ref/django-admin/#django-admin-migrate


Django 1.7-makemigrations无法检测到更改

问题:Django 1.7-makemigrations无法检测到更改

如标题所述,我似乎无法使迁移正常进行。

该应用程序最初的版本低于1.6,因此我知道迁移最初不会进行,并且如果我运行,python manage.py migrate我会得到:

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.

如果我对中的任何模型进行了更改myapp,它仍会像预期的那样未迁移。

但是如果我跑步,python manage.py makemigrations myapp我会得到:

No changes detected in app 'myapp'

似乎与我运行命令的方式或方式无关紧要,它永远不会将应用程序检测为更改,也不会向该应用程序添加任何迁移文件。

是否有任何方法可以迫使应用程序迁移并实质上说“这是我的工作基础”或其他内容?还是我错过了什么?

如果有帮助的话,我的数据库就是PostgreSQL。

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 python manage.py migrate I get:

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.

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

But if I run python manage.py makemigrations myapp I get:

No changes detected in app 'myapp'

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.


回答 0

如果要从django 1.6中制作的现有应用程序进行转换,则需要执行文档中列出的一个第一步(如我所知):

python manage.py makemigrations your_app_label

该文档没有明显表明您需要在命令中添加应用标签,因为它首先告诉您要做的是python manage.py makemigrations失败。最初的迁移是在1.7版中创建的应用程序完成的,但是如果您来自1.6版,则不会进行。有关更多详细信息,请参见文档中的“向应用程序添加迁移”

If you’re changing over from an existing app you made in django 1.6, then you need to do one pre-step (as I found out) listed in the documentation:

python manage.py makemigrations your_app_label

The documentation does not make it obvious that you need to add the app label to the command, as the first thing it tells you to do is python manage.py makemigrations which will fail. The initial migration is done when you create your app in version 1.7, but if you came from 1.6 it wouldn’t have been carried out. See the ‘Adding migration to apps’ in the documentation for more details.


回答 1

可能由于以下原因而发生:

  1. 您没有在以下位置的INSTALLED_APPS列表中添加应用程序settings.py (您必须在应用程序文件夹的apps.py中添加应用程序名称或虚线路径到AppConfig的子类,具体取决于所使用的Django版本)。请参阅文档:INSTALLED_APPS
  2. migrations这些应用程序内没有文件夹。(解决方案:只需创建该文件夹)。
  3. 您没有这些应用程序__init__.py文件migrations夹中的文件。(解决方案:只需创建一个名称为__init__.py的空文件)
  4. __init__.py的应用文件夹中没有文件。(解决方案:只需创建一个名称为__init__.py的空文件)
  5. models.py的应用程序中没有文件
  6. 您的Python类(假定是模型)models.py不会继承django.db.models.Model
  7. 您在定义模型时存在语义错误 models.py

注意: 一个常见的错误是migrations.gitignore文件中添加文件夹。从远程存储库克隆后,本地存储库中的文件migrations夹和/或__init__.py文件将丢失。这导致问题。

我建议通过在文件中添加以下几行来忽略迁移.gitignore文件

*/migrations/*
!*/migrations/__init__.py

This may happen due to the following reasons:

  1. You did not add the app in INSTALLED_APPS list in settings.py (You have to add either the app name or the dotted path to the subclass of AppConfig in apps.py in the app folder, depending on the version of django you are using). Refer documentation: INSTALLED_APPS
  2. You don’t have migrations folder inside those apps. (Solution: just create that folder).
  3. You don’t have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py)
  4. You don’t have an __init__.py file inside the app folder. (Solution: Just create an empty file with name __init__.py)
  5. You don’t have a models.py file in the app
  6. Your Python class (supposed to be a model) in models.py doesn’t inherit django.db.models.Model
  7. You have some semantic mistake in definition of models in models.py

Note: A common mistake is to add migrations folder in .gitignore file. When cloned from remote repo, migrations folder and/or __init__.py files will be missing in local repo. This causes problem.

I suggest to gitignore migration files by adding the following lines to .gitignore file

*/migrations/*
!*/migrations/__init__.py

回答 2

好的,看来我错过了一个明显的步骤,但是在其他人也这样做的情况下发布了此步骤。

当升级到1.7时,我的模型变成了不受管理的(managed = False)-我像True以前一样拥有它们,但似乎已还原。

删除该行(默认情况下为True)然后makemigrations立即运行就构成了一个迁移模块,现在它可以正常工作了。makemigrations将不适用于非托管表(事后看来很明显)

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 (managed = False) – I had them as True before but seems it got reverted.

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


回答 3

我的解决方案未在此处介绍,因此我将其发布。我一直在使用syncdb一个项目-只是为了使其启动并运行。然后,当我尝试开始使用Django迁移时,它首先伪造了它们,然后说是“ OK”,但数据库没有任何反应。

我的解决方案是只删除应用程序的所有迁移文件,以及django_migrations表中应用程序迁移的数据库记录。

然后,我进行了以下初步迁移:

./manage.py makemigrations my_app

其次是:

./manage.py migrate my_app

现在,我可以毫无问题地进行迁移了。

My solution was not covered here so I’m posting it. I had been using syncdb for a project–just to get it up and running. Then when I tried to start using Django migrations, it faked them at first then would say it was ‘OK’ but nothing was happening to the database.

My solution was to just delete all the migration files for my app, as well as the database records for the app migrations in the django_migrations table.

Then I just did an initial migration with:

./manage.py makemigrations my_app

followed by:

./manage.py migrate my_app

Now I can make migrations without a problem.


回答 4

同意@furins。如果一切似乎都井然有序,但是仍然出现此问题,请检查是否有任何名称与要在Model类中添加的属性相同的属性方法。

  1. 删除名称与要添加的属性类似的方法。
  2. manage.py makemigrations my_app
  3. manage.py迁移my_app
  4. 重新添加方法。

Agree with @furins. If everything seems to be in order and yet this problem arises, checkout if there is any property method with same title as the attribute which you are trying to add in the Model class.

  1. Remove method with similar name as attribute you are adding.
  2. manage.py makemigrations my_app
  3. manage.py migrate my_app
  4. Add the methods back.

回答 5

这是一个愚蠢的错误,但是在模型类的字段声明行的末尾有一个逗号,使该行无效。

复制粘贴def时会发生这种情况。从迁移本身定义为数组。

虽然这可能会帮助某人:-)

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 :-)


回答 6

也许我来不及了,但是您是否尝试migrations在应用中创建一个__init__.py文件夹,其中包含文件?

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


回答 7

也许这会帮助某人。我正在使用嵌套应用程序。project.appname,我实际上在INSTALLED_APPS中有project和project.appname。从INSTALLED_APPS中删除项目可以检测到更改。

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.


回答 8

答案是在此stackoverflow帖子上,由cdvv7788 在Django 1.7中进行迁移

如果是第一次迁移该应用程序,则必须使用:

manage.py makemigrations myappname完成后,您可以执行以下操作:

manage.py migration如果您的应用程序已包含在数据库中,请修改其模型并且不更新makemigrations上的更改,则您可能尚未迁移它。将您的模型改回其原始形式,运行第一个命令(使用应用程序名称)并迁移…它将对其进行伪造。完成后,将更改放回模型中,请运行makemigrations并再次进行迁移,它应该可以正常工作。

我遇到了完全相同的麻烦,并且执行上述操作完全正常。

我已将django应用程序移至cloud9,由于某种原因,我从未进行过初始迁移。

The answer is on this stackoverflow post, by cdvv7788 Migrations in Django 1.7

If it is the first time you are migrating that app you have to use:

manage.py makemigrations myappname Once you do that you can do:

manage.py migrate If you had your app in database, modified its model and its not updating the changes on makemigrations you probably havent migrated it yet. Change your model back to its original form, run the first command (with the app name) and migrate…it will fake it. Once you do that put back the changes on your model, run makemigrations and migrate again and it should work.

I was having the exact same trouble and doing the above worked perfectly.

I had moved my django app to cloud9 and for some reason I never caught the initial migration.


回答 9

以下为我工作:

  1. 将应用名称添加到settings.py
  2. 使用’python manage.py makemigrations’
  3. 使用’python manage.py migration’

为我工作:Python 3.4,Django 1.10

Following worked for me:

  1. Add the app name to settings.py
  2. use ‘python manage.py makemigrations’
  3. use ‘python manage.py migrate’

Worked for me: Python 3.4, Django 1.10


回答 10

像我这样不喜欢迁移的人可以使用以下步骤。

  1. 删除您要同步的更改。
  2. 运行python manage.py makemigrations app_label初始迁移。
  3. python manage.py migrate进行更改之前,运行以创建表。
  4. 粘贴您在第一步中删除的更改。
  5. 运行步骤2.和3.。

如果您对这些步骤感到困惑,请阅读迁移文件。更改它们以更正您的架构或删除不需要的文件,但不要忘记更改下一个迁移文件的依赖项;)

我希望这会在将来对某人有所帮助。

People like me who don’t like migrations can use steps below.

  1. Remove changes what you want to sync.
  2. Run python manage.py makemigrations app_label for the initial migration.
  3. Run python manage.py migrate for creating tables before you make changes.
  4. Paste changes which you remove at first step.
  5. Run 2. and 3. steps.

If you confused any of these steps, read the migration files. Change them to correct your schema or remove unwanted files but don’t forget to change next migration file’s dependencies part ;)

I hope this will help someone in future.


回答 11

你要检查settings.pyINSTALLED_APPS列表,并确保所有与模型的应用程序在那里上市。

makemigrations在项目文件夹中运行意味着它将寻找更新与settings.py项目中包含的所有应用程序相关的所有表。包含它后,makemigrations将自动包含该应用程序(这样可以节省大量工作,因此您不必makemigrations app_name为项目/站点中的每个应用程序都运行)。

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

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


回答 12

以防万一您有一个不能由makemigrations标识的特定字段:检查两次是否具有相同名称的属性。

例:

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

# ... later

@property
def field(self):
    pass

该属性将“覆盖”字段定义,因此更改不会被 makemigrations

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:

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

# ... later

@property
def field(self):
    pass

the property will “overwrite” the field definition so changes will not get identified by makemigrations


回答 13

确保您的模型不是abstract。我实际上犯了那个错误,花了一段时间,所以我以为会发布它。

Make sure your model is not abstract. I actually made that mistake and it took a while, so I thought I’d post it.


回答 14

添加此答案是因为只有此方法对我有帮助。

我删除了migrations文件夹run makemigrationsmigrate
它仍然说:没有迁移申请。

我转到migrate文件夹并打开了最后一个创建的文件,
注释了我想要的迁移(已检测到并在此输入)
migrate再次运行。

这基本上是手动编辑迁移文件。
仅当您了解文件内容时,才执行此操作。

Adding this answer because only this method helped me.

I deleted the migrations folder run makemigrations and migrate.
It still said: No migrations to apply.

I went to migrate folder and opened the last created file,
comment the migration I wanted(It was detected and entered there)
and run migrate again.

This basically editing the migrations file manually.
Do this only if you understand the file content.


回答 15

schemamigration my_app --initial重命名旧的迁移文件夹后是否使用过?试试吧。可能会工作。如果不是,请尝试重新创建数据库并进行syncdb + migrate。它对我有用…

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


回答 16

遇到相同的问题确保您在models.py中定义了任何类,您必须必须继承models.Model类。

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

Had the same problem Make sure whatever classes you have defined in models.py, you must have to inherit models.Model class.

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

回答 17

我不得不两次运行makemigrations和各种奇怪的行为时遇到了同样的问题。事实证明,问题的根源在于我正在使用一个函数来设置模型中的默认日期,因此每次我进行makemigrations时,迁移都会检测到更改。这个问题的答案使我走上了正确的轨道:避免进行重新创建日期字段的迁移

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: Avoid makemigrations to re-create date field


回答 18

我最近将Django从1.6升级到1.8,并且几乎没有应用和迁移。我使用了south并schemamigrations在Django 1.6中创建了迁移,而在Django 1.8中删除了该迁移。

当我在升级后添加新型号时,该makemigrations命令未检测到任何更改。然后,我尝试了@drojf建议的解决方案(第一个答案),它工作正常,但未能应用假的初始迁移(python manage.py --fake-initial)。我这样做是因为我的表(旧表)已经创建。

最终,这对我有用,从models.py中删除了新模型(或模型更改),然后必须删除(或重命名以进行安全备份)所有应用程序的迁移文件夹,并manage.py为所有应用程序运行python makemigrations,然后执行了python manage.py migrate --fake-initial。这就像一个魅力。为所有应用创建初始迁移并进行伪初始迁移后,便添加了新模型,并遵循makemigrations该应用的常规流程进行迁移。现在已检测到更改,一切正常。

我只是想在这里分享它,如果有人遇到相同的问题(schemamigrations他们的应用程序有问题),可能会对他们有所帮助:)

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

When I added new models after upgrade, the makemigrations 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 (python manage.py --fake-initial). 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 manage.py makemigrations for all apps, then did python manage.py migrate --fake-initial. 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 makemigrations 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 schemamigrations of south for their apps), it might help them :)


回答 19

也许可以帮助某人,但我遇到了同样的问题。

我已经用序列化程序类和视图创建了两个表。因此,当我想更新时,出现了此错误。

我按照以下步骤操作:

  1. 我做了 .\manage.py makemigrations app
  2. 我执行了 .\manage.py migrate
  3. 我删除了我的两个表 models.py
  4. 我从序列化程序和视图类中删除了对表的所有引用。
  5. 我执行了step 12
  6. 我只是在 models.py
  7. 我再次执行步骤5
  8. 我恢复了所有更改。

如果您正在使用Pycharm,则本地历史记录将非常有帮助。

Maybe that can help someone, I had the same problem.

I’ve already created two tables with the serializer class and the views. So when I wanted to updated, I had this error.

I followed this steps:

  1. I made .\manage.py makemigrations app
  2. I executed .\manage.py migrate
  3. I erased both tables of my models.py
  4. I erased all reference to my tables from serializer and view class.
  5. I executed step 1 and 2.
  6. I retrieved my changes just in the models.py
  7. I executed again step 5.
  8. I restored all my changes.

If you’re working with Pycharm, local history is very helpfull.


回答 20

也许这会帮助某人。

我已经删除了,models.py并希望makemigrations创建DeleteModel语句。

记住要删除*.pyc文件!

Maybe this will help someone.

I’ve deleted my models.py and expected makemigrations to create DeleteModel statements.

Remember to delete *.pyc files!


回答 21

./manage makemigrations
./manage migrate

迁移会跟踪对数据库的更改,因此,如果您从非托管更改为托管,则需要确保您的数据库表与您要处理的模型有关的最新信息。

如果您仍处于开发模式,我个人决定删除我的IDE以及与我的模型相关的django_migrations表中的迁移文件,然后重新运行上述命令。

记住:如果您的迁移在IDE中以_001结尾,在数据库中以_003结尾。Django仅会查看您是否有以_004结尾的迁移来更新任何内容。

2(代码和数据库迁移)是链接在一起的,并且可以协同工作。

快乐的编码。

./manage makemigrations
./manage migrate

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 & _003 in your database. Django will only see if you have a migration ending with _004 for anything to update.

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

Happy coding.


回答 22

  1. 删除您要同步的更改。
  2. 运行python manage.py makemigrations app_label进行初始迁移。
  3. 进行更改之前,请运行python manage.py migration来创建表。
  4. 粘贴您在第一步中删除的更改。
  5. 运行步骤2和3。
  1. Remove changes what you want to sync.
  2. Run python manage.py makemigrations app_label for the initial migration.
  3. Run python manage.py migrate for creating tables before you make changes.
  4. Paste changes which you remove at first step.
  5. Run 2. and 3. steps

回答 23

添加了此答案,因为上面没有其他可用的方法适合我。

在我的情况下,发生了更奇怪的事情(Django 1.7版本),在我的models.py文件的末尾有一个“额外”行(这是一个空行),当我执行python manage.py makemigrations命令时,结果是:“未检测到更改”。

要解决此问题,我删除了我的models.py文件末尾的“空白行”,并再次运行了该命令,所有问题均已修复,并且检测到对models.py所做的所有更改!

Added this answer because none of other available above worked for me.

In my case something even more weird was happening (Django 1.7 Version), In my models.py I had an “extra” line at the end of my file (it was a blank line) and when I executed the python manage.py makemigrations command the result was: “no changes detected”.

To fix this I deleted this “blank line” that was at the end of my models.py file and I did run the command again, everything was fixed and all the changes made to models.py were detected!


回答 24

您可能需要使用以下命令来伪造初始迁移

python manage.py migrate --fake-initial

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

python manage.py migrate --fake-initial

回答 25

首先,此解决方案适用于在heroku服务器上部署期间遇到相同问题的用户,而我也面临相同的问题。

要进行部署,有一个强制性步骤是在settings.py文件中添加django_heroku.settings(locals())。

更改:当我将上述行更改为django_heroku.settings(locals(),database = False)时,它可以正常工作。

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.


回答 26

就我而言,我需要将模型添加到定义了模型的models文件夹的_ init _.py文件中:

from myapp.models.mymodel import MyModel

In my case I needed to add my model to the _init_.py file of the models folder where my model was defined:

from myapp.models.mymodel import MyModel

回答 27

添加我的2c,因为这些解决方案都不适合我,但这确实…

我刚刚运行manage.py squashmigrations并删除了旧的迁移(django.migrations数据库表中的文件和行)。

在最后一个迁移文件中,这样留下了一行:

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

这显然使Django感到困惑,并导致了奇怪的行为:运行manage.py makemigrations my_app将重新创建初始迁移,就好像它们不存在一样。删除replaces...线路可解决问题!

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

I had just run manage.py squashmigrations 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:

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

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


回答 28

python manage.py makemigrations帐户“帐户”的迁移:accounts \ migrations \ 0001_initial.py-创建模型客户-创建模型标签-创建模型产品-创建模型订单

注意:这里的“帐户”是我的应用名称

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