Django 1.7 - makemigations không phát hiện thay đổi


140

Như tiêu đề đã nói, tôi dường như không thể làm cho việc di chuyển hoạt động.

Ứng dụng ban đầu dưới 1.6, vì vậy tôi hiểu rằng việc di chuyển sẽ không có ở đó ban đầu và thực sự nếu tôi chạy python manage.py migratetôi sẽ nhận được:

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.

Nếu tôi thực hiện một thay đổi cho bất kỳ mô hình nào trong myappđó, nó vẫn nói không được điều chỉnh, như mong đợi.

Nhưng nếu tôi chạy, python manage.py makemigrations myapptôi nhận được:

No changes detected in app 'myapp'

Dường như không có vấn đề gì hoặc cách tôi chạy lệnh, nó không bao giờ phát hiện ứng dụng có thay đổi hay không, cũng không thêm bất kỳ tệp di chuyển nào vào ứng dụng.

Có cách nào để buộc một ứng dụng di chuyển và về cơ bản nói "Đây là cơ sở của tôi để làm việc với" hay bất cứ điều gì không? Hay tôi đang thiếu một cái gì đó?

Cơ sở dữ liệu của tôi là một PostgreQuery nếu điều đó có ích gì cả.


Các giải pháp được cung cấp không hiệu quả với tôi vì vậy đây là giải pháp của tôi nếu có ai gặp phải vấn đề tương tự! 1. Xóa các tệp di chuyển trong tất cả các ứng dụng 2. Xóa cơ sở dữ liệu và tạo lại nó 3. chạy makemigations và di chuyển các lệnh PS Trước tiên hãy thử bước 1 và 3. Nếu vẫn còn lỗi, hãy thực hiện các bước 1-3.
Amoroso

Câu trả lời:


187

Nếu bạn đang thay đổi từ một ứng dụng hiện có mà bạn đã tạo trong django 1.6, thì bạn cần thực hiện một bước trước (như tôi đã tìm thấy) được liệt kê trong tài liệu:

python Manage.py makemigations your_app_label

Tài liệu này không làm rõ rằng bạn cần thêm nhãn ứng dụng vào lệnh, vì điều đầu tiên nó bảo bạn làm là python manage.py makemigrationssẽ thất bại. Việc di chuyển ban đầu được thực hiện khi bạn tạo ứng dụng của mình trong phiên bản 1.7, nhưng nếu bạn đến từ 1.6 thì sẽ không được thực hiện. Xem phần 'Thêm di chuyển vào ứng dụng' trong tài liệu để biết thêm chi tiết.


1
Câu trả lời hay cho những người đến từ Django 1.6! Cảm ơn!
David D.

1
Nếu tôi có nhiều hơn một ứng dụng thì sao? Tôi có nên python manage.py makemigrations APP_LABELcho mỗi người?
Alston

1
Theo Django 1.9 ở đây và ứng dụng của tôi đã được tạo ./manage.py startapp, nhưng tôi vẫn phải đề cập rõ ràng đến nhãn
maxbellec

50

Điều này có thể xảy ra do các lý do sau:

  1. Bạn đã không thêm ứng dụng vào INSTALLED_APPSdanh sách trong settings.py (Bạn phải thêm tên ứng dụng hoặc đường dẫn chấm vào lớp con của AppConfig trong apps.py trong thư mục ứng dụng, tùy thuộc vào phiên bản django bạn đang sử dụng). Tham khảo tài liệu: INSTALLED_APPS
  2. Bạn không có migrationsthư mục bên trong các ứng dụng đó. (Giải pháp: chỉ cần tạo thư mục đó).
  3. Bạn không có __init__.pytập tin trong migrationsthư mục của những ứng dụng đó. (Giải pháp: Chỉ cần tạo một tệp trống có tên __init__.py )
  4. Bạn không có một __init__.pytập tin trong thư mục ứng dụng. (Giải pháp: Chỉ cần tạo một tệp trống có tên __init__.py )
  5. Bạn không có models.pytệp trong ứng dụng
  6. Lớp Python của bạn (được coi là một mô hình) models.pykhông kế thừadjango.db.models.Model
  7. Bạn có một số sai lầm ngữ nghĩa trong định nghĩa của các mô hình trong models.py

Lưu ý: Một lỗi phổ biến là thêm migrationsthư mục trong .gitignoretệp. Khi được sao chép từ repo từ xa, migrationsthư mục và / hoặc __init__.pytệp sẽ bị thiếu trong repo cục bộ. Điều này gây ra vấn đề.

Tôi đề nghị gitignore tệp di chuyển bằng cách thêm các dòng sau vào .gitignoretệp

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

1
Tôi đã nhân bản dự án của mình và thư mục di chuyển không được đẩy vào repo vì vậy tôi phải thêm giám đốc di chuyển sau đó tôi đã thêm init .py và tôi đã có thể thực hiện di chuyển. Nhờ bạn
Junaid

Tôi đã xóa nội dung của thư mục / di chuyển của mình để "đặt lại" những thứ trong dự án mà tôi chưa triển khai. Tôi vô tình xóa __init__.pythư mục cùng với việc di chuyển.
Seth

Điều này đã làm điều đó cho tôi .... You don't have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py).. và nó được gây ra bằng cách thêm các tệp vào.gitignore
lukik

1
Tại sao tập tin init .py rất quan trọng trong thư mục di chuyển? để thực hiện di chuyển? Tôi có thể đào sâu hơn về logic này ở đâu?
Nimish Bansal

1
@NimishBansal Till __init__.pytập tin python 3.3 được yêu cầu trong một thư mục để làm cho nó được coi là một gói python. xem cái này
Mohammed Shareef C

29

Ok, có vẻ như tôi đã bỏ lỡ một bước rõ ràng, nhưng đăng bài này trong trường hợp bất cứ ai khác làm điều tương tự.

Khi nâng cấp lên 1.7, các mô hình của tôi trở nên không được quản lý ( managed = False) - Tôi đã có chúng như Truetrước đây nhưng dường như nó đã được hoàn nguyên.

Xóa dòng đó (Để mặc định thành True) và sau đó chạy makemigrationsngay lập tức tạo một mô-đun di chuyển và bây giờ nó đang hoạt động. makemigrationssẽ không hoạt động trên các bảng không được quản lý (Điều này là hiển nhiên trong nhận thức muộn)


4
Vui lòng làm rõ - bạn đã thay đổi / thêm "Managed = false" ở đâu? Tôi đang gặp vấn đề tương tự
Ycon

1
Tôi không có mã đó nữa, nhưng tôi nghĩ là một tài sản của lớp nếu tôi nhớ chính xác.
TyrantWave

1
Điểm tốt. Lưu ý rằng manage.py inspectdbthêm quản lý = Sai! trong trường hợp bạn nhập cơ sở dữ liệu cũ, bạn phải điều chỉnh cẩn thận!
Alessandro Dentella

@TyrantWave, bạn đã lưu ngày của tôi. Cảm ơn rất nhiều.
Utkarsh Sharma

hãy chắc chắn rằng bạn app_labelgiống nhau
Luv33preet

19

Giải pháp của tôi không được đề cập ở đây vì vậy tôi đang đăng nó. Tôi đã sử dụng syncdbcho một dự án, chỉ để khởi động và chạy nó. Sau đó, khi tôi cố gắng bắt đầu sử dụng di chuyển Django, ban đầu nó giả mạo chúng sau đó sẽ nói rằng 'OK' nhưng không có gì xảy ra với cơ sở dữ liệu.

Giải pháp của tôi là chỉ xóa tất cả các tệp di chuyển cho ứng dụng của mình, cũng như các bản ghi cơ sở dữ liệu cho các di chuyển ứng dụng trong django_migrationsbảng.

Sau đó, tôi mới thực hiện một di chuyển ban đầu với:

./manage.py makemigrations my_app

theo dõi bởi:

./manage.py migrate my_app

Bây giờ tôi có thể thực hiện di chuyển mà không có vấn đề.


FYI: điều quan trọng là anh ấy nói ở đây, "các tập tin, cũng như các hồ sơ cơ sở dữ liệu." Nếu bạn xóa các bản ghi cơ sở dữ liệu nhưng cũng không phải các tệp (ngoại trừ __init.py__, nó sẽ không hoạt động.
Mike Robinson

15

Đồng ý với @furins. Nếu mọi thứ dường như theo thứ tự và vấn đề này phát sinh, hãy kiểm tra xem có phương thức thuộc tính nào có cùng tiêu đề với thuộc tính mà bạn đang cố gắng thêm trong lớp Model không.

  1. Xóa phương thức có tên tương tự như thuộc tính bạn đang thêm.
  2. quản lý makemigations my_app
  3. Manage.txt di chuyển my_app
  4. Thêm các phương thức trở lại.

11

Đây là một sai lầm ngu ngốc khi thực hiện, nhưng có thêm dấu phẩy ở cuối dòng khai báo trường trong lớp mô hình, làm cho dòng này không có hiệu lực.

Nó xảy ra khi bạn sao chép dán def. từ di chuyển, mà chính nó được định nghĩa là một mảng.

Mặc dù có lẽ điều này sẽ giúp ai đó :-)


1
Nhận xét của bạn đã giúp tôi tìm ra vấn đề của mình! Tôi đã không có dấu phẩy ở cuối lựa chọn cuối cùng trong danh sách lựa chọn..thường như Django rất cảm động.
Tối đa

1
@Maxim: đó không chắc là nguyên nhân của vấn đề của bạn: danh sách không có dấu phẩy ở cuối vẫn là danh sách. Một vấn đề khác là bộ dữ liệu: nếu bạn chỉ có 1 phần tử trong một bộ, bạn cần có dấu phẩy sau nó.
blueFast

anh bạn đã tiết kiệm cho tôi rất nhiều thời gian @dangonfast: trong định nghĩa Mô hình, đó thực sự là một vấn đề.
MrE

11

Có thể tôi đã quá muộn nhưng bạn đã thử để có một migrationsthư mục trong ứng dụng của mình với một __init__.pytệp trong đó chưa?


1
Nếu bạn có "makemigations" này sẽ tạo ra các chuyển đổi cho ứng dụng. Nếu không, nó sẽ yêu cầu bạn chạy makemigations app_name (tạo tệp này)
Scott Warren

7

Có lẽ điều này sẽ giúp được ai đó. Tôi đã sử dụng một ứng dụng lồng nhau. project.appname và tôi thực sự đã có dự án và project.appname trong INSTALLED_APPS. Xóa dự án khỏi INSTALLED_APPS cho phép phát hiện các thay đổi.


7

Câu trả lời là trên bài đăng stackoverflow này, bởi cvv7788 Di chuyển trong Django 1.7

Nếu đây là lần đầu tiên bạn di chuyển ứng dụng đó, bạn phải sử dụng:

Manage.txt makemigations myappname Một khi bạn làm điều đó bạn có thể làm:

Manage.txt di chuyển Nếu bạn có ứng dụng của mình trong cơ sở dữ liệu, đã sửa đổi mô hình của nó và ứng dụng không cập nhật các thay đổi về cách thức mà bạn có thể chưa di chuyển nó. Thay đổi mô hình của bạn trở lại dạng ban đầu, chạy lệnh đầu tiên (với tên ứng dụng) và di chuyển ... nó sẽ giả mạo nó. Khi bạn thực hiện điều đó, hãy đặt lại các thay đổi trên mô hình của bạn, chạy makemigations và di chuyển lại và nó sẽ hoạt động.

Tôi đã có cùng một rắc rối chính xác và làm những điều trên làm việc hoàn hảo.

Tôi đã chuyển ứng dụng django của mình sang cloud9 và vì một số lý do tôi không bao giờ bắt gặp sự di chuyển ban đầu.


7

Sau đây làm việc cho tôi:

  1. Thêm tên ứng dụng vào settings.py
  2. sử dụng 'python Manage.py makemigations'
  3. sử dụng 'python Manage.py di chuyển'

Làm việc cho tôi: Python 3,4, Django 1.10


6

Những người như tôi không thích di cư có thể sử dụng các bước dưới đây.

  1. Xóa các thay đổi những gì bạn muốn đồng bộ hóa.
  2. Chạy python manage.py makemigrations app_labelcho di chuyển ban đầu.
  3. Chạy python manage.py migrateđể tạo bảng trước khi bạn thay đổi.
  4. Dán những thay đổi mà bạn loại bỏ ở bước đầu tiên.
  5. Chạy 2. và 3. bước.

Nếu bạn nhầm lẫn bất kỳ bước nào trong số này, hãy đọc các tệp di chuyển. Thay đổi chúng để sửa lược đồ của bạn hoặc xóa các tệp không mong muốn nhưng đừng quên thay đổi phần phụ thuộc của tệp di chuyển tiếp theo;)

Tôi hy vọng điều này sẽ giúp được ai đó trong tương lai.


5

Bạn muốn kiểm tra settings.pytrong INSTALLED_APPSdanh sách và đảm bảo tất cả các ứng dụng có mô hình được liệt kê trong đó.

Chạy makemigrationstrong thư mục dự án có nghĩa là nó sẽ tìm cách cập nhật tất cả các bảng liên quan đến tất cả các ứng dụng có trong settings.pydự án. Khi bạn đưa nó vào, makemigrationssẽ tự động bao gồm ứng dụng (điều này giúp tiết kiệm rất nhiều công việc để bạn không phải chạy makemigrations app_namecho mọi ứng dụng trong dự án / trang web của bạn).


5

Chỉ trong trường hợp bạn có một trường cụ thể không được xác định bởi các định nghĩa: kiểm tra hai lần nếu bạn có một tài sản có cùng tên.

thí dụ:

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

# ... later

@property
def field(self):
    pass

thuộc tính sẽ "ghi đè" định nghĩa trường để thay đổi sẽ không được xác định bởi makemigrations


Bummer liên quan là có một trường không đúng định dạng mà vẫn thoát khỏi xác nhận / kiểm tra. Tôi đã xác định hourly_rate = models.DecimalField(thiếu dấu vết '()') và nó chỉ thất bại trong âm thầm.
hiền nhân

5

Hãy chắc chắn rằng mô hình của bạn không abstract. Tôi thực sự đã mắc sai lầm đó và phải mất một thời gian, vì vậy tôi nghĩ rằng tôi đã đăng nó.


4

Thêm câu trả lời này vì chỉ có phương pháp này giúp tôi.

Tôi đã xóa migrationsthư mục chạy makemigrationsmigrate.
Nó vẫn nói: Không di chuyển để áp dụng.

Tôi đã đi đến migratethư mục và mở tệp được tạo cuối cùng,
nhận xét di chuyển tôi muốn (Nó được phát hiện và nhập vào đó)
và chạy migratelại.

Điều này về cơ bản chỉnh sửa các tập tin di chuyển bằng tay.
Làm điều này chỉ khi bạn hiểu nội dung tập tin.


1
Cảm ơn bạn rất nhiều! Điều này đã giúp
Sharrial512

3

Bạn đã sử dụng schemamigration my_app --initialsau khi đổi tên thư mục di chuyển cũ? Thử nó. Có thể làm việc. Nếu không - hãy thử tạo lại cơ sở dữ liệu và thực hiện di chuyển syncdb +. Nó làm việc cho tôi ...


10
Không có lệnh schemamigrationnào tồn tại - Tôi nghĩ đó là một phần của miền Nam? Hiện tại tôi không có thư mục di chuyển. Loại bỏ tôi models.pyvà chạy lại inspectdbdường như không làm gì cả.
TyrantWave

2
schemamigrationlà từ miền Nam. makemigrationslà sự thay thế của nó.
Craig Labenz

2
Điều này vẫn còn hiệu lực. Nhưng nó đã đổi thànhmakemigrations --empty
Iulius Curt

2

Có cùng một vấn đề Hãy chắc chắn rằng bất kỳ lớp nào bạn đã xác định trong mô hình, bạn phải kế thừa mô hình. Lớp mô hình.

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

1

Tôi đã có cùng một vấn đề với việc phải chạy makemigations hai lần và tất cả các loại hành vi lạ. Hóa ra gốc rễ của vấn đề là tôi đã sử dụng một hàm để đặt ngày mặc định trong các mô hình của mình để việc di chuyển phát hiện ra một sự thay đổi mỗi khi tôi chạy makemigations. Câu trả lời cho câu hỏi này đưa tôi đi đúng hướng: Tránh định hướng để tạo lại trường ngày


1

Gần đây tôi đã nâng cấp Django từ 1.6 lên 1.8 và có một vài ứng dụng và di chuyển cho chúng. Tôi đã sử dụng về phía nam và schemamigrationsđể tạo ra sự di cư trong Django 1.6, được bỏ trong Django 1.8.

Khi tôi thêm các mô hình mới sau khi nâng cấp, makemigrationslệnh không phát hiện bất kỳ thay đổi nào. Và sau đó tôi đã thử giải pháp được đề xuất bởi @drojf (câu trả lời đầu tiên), nó hoạt động tốt, nhưng không áp dụng di chuyển ban đầu giả ( python manage.py --fake-initial). Tôi đã làm điều này vì các bảng của tôi (các bảng cũ) đã được tạo.

Cuối cùng, điều này đã giúp tôi, loại bỏ các mô hình mới (hoặc thay đổi mô hình) khỏi mô hình và sau đó phải xóa (hoặc đổi tên để sao lưu an toàn) thư mục di chuyển của tất cả các ứng dụng và chạy manage.pymô phỏng python cho tất cả các ứng dụng, sau đó đã làm python manage.py migrate --fake-initial. Điều này làm việc như một nét duyên dáng. Khi di chuyển ban đầu được tạo cho tất cả các ứng dụng và di chuyển ban đầu giả, sau đó thêm các mô hình mới và tuân theo quy trình makemigrationsvà di chuyển thường xuyên trên ứng dụng đó. Những thay đổi đã được phát hiện và mọi thứ đều ổn.

Tôi chỉ nghĩ đến việc chia sẻ nó ở đây, nếu ai đó phải đối mặt với cùng một vấn đề (có schemamigrationsphía nam cho các ứng dụng của họ), nó có thể giúp họ :)


1

Có lẽ điều đó có thể giúp ai đó, tôi đã có cùng một vấn đề.

Tôi đã tạo hai bảng với lớp serializer và các khung nhìn. Vì vậy, khi tôi muốn cập nhật, tôi đã gặp lỗi này.

Tôi đã làm theo các bước này:

  1. tôi đã làm .\manage.py makemigrations app
  2. Tôi đã thi hành .\manage.py migrate
  3. Tôi đã xóa cả hai bảng của tôi models.py
  4. Tôi đã xóa tất cả các tham chiếu đến các bảng của tôi khỏi serializer và xem lớp.
  5. Tôi thực hiện bước 12.
  6. Tôi đã lấy các thay đổi của mình chỉ trong models.py
  7. Tôi thực hiện lại bước 5.
  8. Tôi đã khôi phục tất cả các thay đổi của tôi.

Nếu bạn đang làm việc với Pycharm, lịch sử địa phương rất hữu ích.


1

Có lẽ điều này sẽ giúp được ai đó.

Tôi đã xóa models.pyvà dự kiến ​​sẽ makemigrationstạo DeleteModelbáo cáo.

Nhớ xóa *.pyctập tin!


1
./manage makemigrations
./manage migrate

Di chuyển theo dõi các thay đổi thành DB, vì vậy nếu bạn thay đổi từ không được quản lý sang được quản lý, bạn sẽ cần đảm bảo rằng bảng cơ sở dữ liệu của bạn được cập nhật liên quan đến Mô hình bạn đang xử lý.

Nếu bạn vẫn ở chế độ dev, cá nhân tôi đã quyết định xóa các tệp di chuyển trong IDE của tôi cũng như trong bảng django_migations liên quan đến Model của tôi và chạy lại lệnh trên.

HÃY NHỚ: nếu bạn có một di chuyển kết thúc bằng _001 trong IDE & _003 trong cơ sở dữ liệu của bạn. Django sẽ chỉ xem nếu bạn có một di chuyển kết thúc bằng _004 cho bất cứ điều gì để cập nhật.

2 (di chuyển mã & db) được liên kết và hoạt động song song.

Chúc mừng mã hóa.


1
  1. Xóa các thay đổi những gì bạn muốn đồng bộ hóa.
  2. Chạy python Manage.py makemigations app_label cho lần di chuyển ban đầu.
  3. Chạy python Manage.txt di chuyển để tạo bảng trước khi bạn thay đổi.
  4. Dán những thay đổi mà bạn loại bỏ ở bước đầu tiên.
  5. Chạy 2. và 3. bước

0

Đã thêm câu trả lời này vì không có câu trả lời nào khác ở trên làm việc cho tôi.

Trong trường hợp của tôi một cái gì đó thậm chí kỳ lạ hơn đã xảy ra ( Django 1,7 Version ), trong tôi models.py Tôi đã có một "thêm" dòng ở phần cuối của tập tin của tôi (đó là một dòng trống) và khi tôi thực hiện các python manage.py makemigrationslệnh kết quả là: "không phát hiện thay đổi".

Để khắc phục tôi này xóa này "dòng trống" đó là ở phần cuối của tôi models.py tập tin và tôi đã chạy lệnh một lần nữa, tất cả mọi thứ đã được cố định và tất cả các thay đổi được thực để models.py đã được phát hiện!


Vâng, trong django 2.0 +, tôi tin rằng dòng trống đó, tôi đã phải làm ngược lại với những gì bạn đã làm
Sumit Kumar Saha

@SumitKumarSaha haha ​​Tôi đang sử dụng phiên bản Django 1.7 hiện tại và dòng trống đó là lý do của 2 giờ cố gắng mọi thứ để giải quyết lỗi di chuyển. Cảm ơn đã chia sẻ Sumit. Chúc một ngày tốt lành
Huskie 17/2/18

0

Bạn có thể cần phải giả mạo di chuyển ban đầu bằng cách sử dụng lệnh bên dưới

python manage.py migrate --fake-initial

0

Đầu tiên giải pháp này được áp dụng cho những người đang gặp phải vấn đề tương tự trong quá trình triển khai trên máy chủ heroku, tôi đã gặp phải vấn đề tương tự.

Để triển khai, có một bước bắt buộc là thêm django_heroku.sinstall (locals ()) trong tệp settings.txt.

Thay đổi: Khi tôi thay đổi dòng trên thành django_heroku.sinstall (locals (), cơ sở dữ liệu = Sai), nó hoạt động hoàn hảo.


0

Trong trường hợp của tôi, tôi cần thêm mô hình của mình vào tệp _ init _.py của thư mục mô hình nơi mô hình của tôi được xác định:

from myapp.models.mymodel import MyModel

-1

Thêm 2c của tôi, vì không có giải pháp nào trong số này làm việc cho tôi, nhưng điều này đã ...

Tôi vừa chạy manage.py squashmigrationsvà xóa các di chuyển cũ (cả tệp và dòng trong bảng cơ sở dữ liệu django.migations).

Điều này để lại một dòng như thế này trong tệp di chuyển cuối cùng:

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

Điều này rõ ràng khiến Django bối rối và gây ra hành vi kỳ lạ: chạy manage.py makemigrations my_appsẽ tạo lại sự di chuyển ban đầu như thể không có gì tồn tại. Loại bỏ các replaces...dòng cố định vấn đề!


-1

python Manage.py makemigations tài khoản Di chuyển cho 'tài khoản': tài khoản \ di chuyển \ 0001_initial.py - Tạo mô hình Khách hàng - Tạo thẻ mô hình - Tạo mô hình Sản phẩm - Tạo mô hình Đặt hàng

Lưu ý: ở đây "tài khoản" là tên ứng dụng của tôi

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.