Django 1.7-변경 사항을 감지하지 못하는 마이그레이션
제목에서 알 수 있듯이 마이그레이션이 작동하지 않는 것 같습니다.
응용 프로그램은 원래 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 데이터베이스이므로 전혀 도움이되지 않습니다.
django 1.6에서 만든 기존 앱에서 변경하는 경우 설명서에 나열된 하나의 사전 단계를 수행해야합니다.
python manage.py makemigrations your_app_label
설명서에서 지시하는 첫 번째 작업 python manage.py makemigrations
이 실패 할 것이므로 설명서에 앱 레이블을 추가해야한다는 것이 명확하지 않습니다 . 초기 마이그레이션은 버전 1.7에서 앱을 만들 때 수행되지만 1.6에서 온 경우에는 수행되지 않았습니다. 자세한 내용은 설명서의 '앱에 마이그레이션 추가' 를 참조하십시오.
다음과 같은 이유로 발생할 수 있습니다.
INSTALLED_APPS
목록에 앱을 추가하지 않았습니다settings.py
( 사용중인 django 버전에 따라 app 폴더의 apps.py에서 appConfig의 서브 클래스에 앱 이름 또는 점으로 구분 된 경로 를 추가해야 함 ). INSTALLED_APPS 설명서를 참조하십시오migrations
해당 앱 안에 폴더 가 없습니다 . (해결 방법 : 해당 폴더를 작성하십시오).- 해당 앱의 폴더
__init__.py
안에 파일 이 없습니다migrations
. (해결 방법 : 이름이 __init__.py 인 빈 파일을 만드십시오 ) __init__.py
앱 폴더 안에 파일 이 없습니다 . (해결 방법 : 이름이 __init__.py 인 빈 파일을 만드십시오 )models.py
앱에 파일 이 없습니다- 파이썬 클래스 (모델로 가정)는
models.py
상속받지 않습니다.django.db.models.Model
- 모델 정의에서 의미 상 실수가 있습니다.
models.py
참고 : 일반적인 실수는 파일 에 migrations
폴더 를 추가하는 것입니다 .gitignore
. 원격 저장소에서 복제하면 migrations
폴더 및 / 또는 __init__.py
파일이 로컬 저장소에 없습니다. 이로 인해 문제가 발생합니다.
나는에 다음 라인을 추가하여 마이그레이션 파일을 gitignore하는 것이 좋습니다 .gitignore
파일을
*/migrations/*
!*/migrations/__init__.py
좋아, 분명한 단계를 놓친 것처럼 보이지만 다른 사람이 동일한 경우를 대비하여 게시하십시오.
1.7로 업그레이드 할 때 내 모델이 관리되지 않게되었습니다 ( managed = False
) True
. 이전 과 같이 모델이 있지만 되 돌린 것 같습니다.
해당 줄을 제거하고 (기본값은 True로 설정) makemigrations
즉시 실행 하면 마이그레이션 모듈이 만들어져 작동합니다. makemigrations
관리되지 않는 테이블에서 작동하지 않습니다 (후시에는 분명합니다)
내 솔루션은 여기에서 다루지 않았으므로 게시하고 있습니다. 내가 사용하고있었습니다 syncdb
- 단지 프로젝트 그것을 얻기 위해에 대한 실행. 그런 다음 Django 마이그레이션을 사용하려고 시도했을 때 처음에는 가짜 였고 'OK'라고 말했지만 데이터베이스에는 아무런 변화가 없었습니다.
내 솔루션은 내 응용 프로그램에 대한 모든 마이그레이션 파일을 삭제하는 것이 었습니다 뿐만 아니라 로의 응용 프로그램 마이그레이션에 대한 데이터베이스 레코드 django_migrations
테이블.
그런 다음 방금 초기 마이그레이션을 수행했습니다.
./manage.py makemigrations my_app
뒤에 :
./manage.py migrate my_app
이제 문제없이 마이그레이션을 수행 할 수 있습니다.
@furins에 동의하십시오. 모든 것이 정상인 것처럼 보이지만이 문제가 발생하면 Model 클래스에 추가하려는 속성과 제목이 같은 속성 메소드가 있는지 확인하십시오.
- 추가하려는 속성과 이름이 비슷한 메소드를 제거하십시오.
- manage.py makemigrations my_app
- manage.py 마이그레이션 my_app
- 메소드를 다시 추가하십시오.
이것은 어리석은 실수이지만 모델 클래스의 필드 선언 줄 끝에 추가 쉼표가 있으면 해당 줄이 적용되지 않습니다.
데프를 복사하여 붙여 넣을 때 발생합니다. 자체적으로 배열로 정의 된 마이그레이션에서
어쩌면 이것은 누군가를 도울 것입니다 :-)
어쩌면 너무 늦었지만 migrations
앱에 __init__.py
파일 이있는 폴더 를 만들려고 했 습니까?
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.
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.
Following worked for me:
- Add the app name to settings.py
- use 'python manage.py makemigrations'
- use 'python manage.py migrate'
Worked for me: Python 3.4, Django 1.10
People like me who don't like migrations can use steps below.
- Remove changes what you want to sync.
- Run
python manage.py makemigrations app_label
for the initial migration. - Run
python manage.py migrate
for creating tables before you make changes. - Paste changes which you remove at first step.
- 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.
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).
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
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.
Make sure your model is not abstract
. I actually made that mistake and it took a while, so I thought I'd post it.
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...
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()
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
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 :)
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:
- I made
.\manage.py makemigrations app
- I executed
.\manage.py migrate
- I erased both tables of my
models.py
- I erased all reference to my tables from serializer and view class.
- I executed step
1
and2
. - I retrieved my changes just in the
models.py
- I executed again step
5
. - I restored all my changes.
If you're working with Pycharm, local history is very helpfull.
Maybe this will help someone.
I've deleted my models.py
and expected makemigrations
to create DeleteModel
statements.
Remember to delete *.pyc
files!
./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.
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!
You may need to fake the initial migrations using the command below
python manage.py migrate --fake-initial
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!
참고URL : https://stackoverflow.com/questions/24912173/django-1-7-makemigrations-not-detecting-changes
'IT story' 카테고리의 다른 글
각도 2 옵션 경로 매개 변수 (0) | 2020.06.24 |
---|---|
MySQL Workbench : 연결을 유지하는 방법 (0) | 2020.06.24 |
Laravel 마이그레이션을 통해 타임 스탬프 열의 기본값을 현재 타임 스탬프로 설정하려면 어떻게해야합니까? (0) | 2020.06.23 |
angularjs에서 날짜 형식을 지정하는 방법 (0) | 2020.06.23 |
다형성 : 왜“ArrayList list = new ArrayList”대신“List list = new ArrayList”를 사용합니까? (0) | 2020.06.23 |