Cách tiếp cận được đề xuất để đặt lại lịch sử di chuyển bằng Django South là gì?

Tôi đã tích lũy được khá nhiều lần di chuyển bằng Nam (0,7) và Django (1.1.2) đang bắt đầu tiêu tốn khá nhiều thời gian trong các bài kiểm tra đơn vị của tôi. Tôi muốn đặt lại đường cơ sở và bắt đầu một bộ di chuyển mới. Tôi đã xem lại tài liệu hướng Nam , thực hiện tìm kiếm Google / Stackoverflow thông thường (ví dụ: "django phía nam (đặt lại HOẶC xóa HOẶC xóa) lịch sử di chuyển") và không tìm thấy điều gì rõ ràng.

Một cách tiếp cận tôi đã dự tính sẽ bao gồm "bắt đầu lại" bằng cách "xóa" Nam hoặc "xóa" lịch sử theo cách thủ công (ví dụ: xóa bảng db, xóa tệp di chuyển khỏi giám đốc di chuyển) và chỉ chạy lại,

./manage.py schemamigration southtut --initial

Vì vậy, nếu bất cứ ai đã làm điều này trước đây và có một số lời khuyên / đề xuất, họ sẽ được đánh giá rất cao.

EDIT - Tôi đang đặt một bình luận bên dưới ở đầu bài này vì điều quan trọng là phải đọc nó trước câu trả lời> được chấp nhận sau @andybak

@Dominique: Lời khuyên của bạn về việc quản lý cài đặt lại phía nam rất nguy hiểm và có thể phá hủy cơ sở dữ liệu nếu có bất kỳ ứng dụng bên thứ ba nào sử dụng phía nam trong dự án, như được chỉ ra bởi @thnee bên dưới. Vì câu trả lời của bạn có rất nhiều câu hỏi, tôi thực sự đánh giá cao nếu bạn có thể chỉnh sửa nó và thêm ít nhất một cảnh báo về điều này, hoặc (thậm chí tốt hơn) thay đổi nó để phản ánh cách tiếp cận @hobs (cũng thuận tiện, nhưng không ảnh hưởng đến các ứng dụng khác) - cảm ơn! - chrisv ngày 26 tháng 3 năm 13 lúc 9:09

Câu trả lời được chấp nhận sau đây:

Đầu tiên, một câu trả lời của tác giả miền Nam :

Miễn là bạn cẩn thận thực hiện đồng thời trên tất cả các triển khai, không nên có bất kỳ vấn đề nào với việc này. Cá nhân, tôi sẽ làm:

    rm -r appname/migrations/ 
    ./manage.py reset south 
    ./manage.py convert_to_south appname 

(Lưu ý rằng reset southphần của LỪA xóa các bản ghi di chuyển cho TẤT CẢ các ứng dụng, vì vậy hãy đảm bảo bạn chạy hai dòng khác cho tất cả các ứng dụng hoặc xóa có chọn lọc).

Cuộc convert_to_southgọi ở cuối tạo ra một di chuyển mới và giả mạo áp dụng nó (vì cơ sở dữ liệu của bạn đã có các bảng tương ứng). Không cần phải bỏ tất cả các bảng ứng dụng trong suốt quá trình.

Đây là những gì tôi đang làm trên máy chủ dev + sản ​​xuất của mình khi tôi cần loại bỏ tất cả các chuyển đổi dev không cần thiết này:

1. Hãy chắc chắn rằng chúng ta có cùng một lược đồ DB ở cả hai bên
2. xóa mọi thư mục di chuyển ở cả hai bên
3. chạy ./manage.py đặt lại phía nam (như bài đăng đã nói) ở cả hai bên = xóa bảng phía nam *
4. chạy ./manage.py convert_to_south ở cả hai bên (giả mạo di chuyển 0001)
5. sau đó tôi có thể bắt đầu lại để thực hiện di chuyển và đẩy các thư mục di chuyển trên máy chủ của mình

* ngoại trừ nếu bạn chỉ muốn xóa một ứng dụng trong số những ứng dụng khác, nếu vậy bạn sẽ cần chỉnh sửa bảng south_history của mình và chỉ xóa các mục về ứng dụng của bạn.

Nếu bạn cần chọn lọc (chỉ một ứng dụng), hãy thiết lập lại quá trình di chuyển mất quá nhiều thời gian, điều này có hiệu quả với tôi.

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

Đừng quên khôi phục thủ công bất kỳ phụ thuộc nào trên các ứng dụng khác bằng cách thêm các dòng như depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial"))vào <app-dir>/migrations/0001_initial.pytệp của bạn , làm thuộc tính đầu tiên trong lớp di chuyển của bạn ngay bên dưới class Migration(SchemaMigration):.

Sau đó, bạn có thể ./manage.py migrate <app-name> --fake --delete-ghost-migrationstrên các môi trường khác, theo câu trả lời SO này . Tất nhiên, nếu bạn giả mạo xóa hoặc giả, migrate zerobạn sẽ cần xóa thủ công mọi bảng db còn sót lại bằng cách di chuyển như thế này .

Một tùy chọn hạt nhân hơn là ./manage.py migrate --fake --delete-ghost-migrationstrên máy chủ triển khai trực tiếp theo sau là một khối vuông [của tôi]. Sau đó, đường ống đổ vào [my] sql trên các môi trường nơi bạn cần db di chuyển, được điền đầy đủ. Nam biết, tôi biết, nhưng làm việc cho tôi.

Nhờ những câu trả lời của Dominique Guardiola và hobs, nó đã giúp tôi giải quyết một vấn đề khó khăn. Tuy nhiên, có một vài vấn đề với giải pháp, đây là vấn đề của tôi.

Sử dụng manage.py reset southlà không phải là một ý tưởng tốt nếu bạn có bất kỳ ứng dụng của bên thứ ba sử dụng miền Nam, ví dụ django-cms(về cơ bản tất cả mọi thứ sử dụng miền Nam).

reset south sẽ xóa tất cả lịch sử di chuyển cho tất cả các ứng dụng mà bạn đã cài đặt.

Bây giờ hãy xem xét rằng bạn nâng cấp lên phiên bản mới nhất django-cms, nó sẽ chứa các chuyển đổi mới như thế nào 0009_do_something.py. Nam chắc chắn sẽ bị nhầm lẫn khi bạn cố gắng chạy di cư đó mà không cần phải 0001thông qua 0008trong lịch sử di cư.

Sẽ tốt hơn / an toàn hơn khi chỉ chọn lại các ứng dụng mà bạn đang duy trì .

Trước hết, hãy đảm bảo rằng các ứng dụng của bạn không có bất kỳ sự không đồng bộ nào giữa các lần di chuyển trên đĩa và việc di chuyển đã được thực hiện trên cơ sở dữ liệu. Nếu không sẽ đau đầu.

1. Xóa lịch sử di chuyển cho các ứng dụng của tôi

sql> delete from south_migrationhistory where app_name = 'my_app';

2. Xóa di chuyển cho các ứng dụng của tôi

$ rm -rf my_app/migrations/

3. Tạo di chuyển ban đầu mới cho ứng dụng của tôi

$ ./manage.py schemamigration --initial my_app

4. Fake thực hiện di chuyển ban đầu cho các ứng dụng của tôi

Điều này chèn các di chuyển vào south_migrationhistorymà không chạm vào các bảng thực tế:

$ ./manage.py migrate --fake my_app

Bước 3 và 4 thực sự chỉ là một biến thể dài hơn manage.py convert_to_south my_app, nhưng tôi thích điều khiển thêm đó, trong tình huống tế nhị như sửa đổi cơ sở dữ liệu sản xuất.

Giống như thnee (xem câu trả lời của cô ấy), chúng tôi đang sử dụng cách tiếp cận nhẹ nhàng hơn với đề xuất của tác giả miền Nam (Andrew Godwin) được trích dẫn ở nơi khác ở đây và chúng tôi tách biệt những gì chúng tôi làm với cơ sở mã từ những gì chúng tôi làm với cơ sở dữ liệu, trong khi triển khai , bởi vì chúng tôi cần các triển khai có thể lặp lại:

Những gì chúng tôi làm trong mã:

# Remove all the migrations from the app
$ rm -fR appname/migrations
# Make the first migration (don't touch the database)
$ ./manage.py schemamigration appname --initial

Chúng ta sẽ làm gì với cơ sở dữ liệu khi mã đó được triển khai

# Fake the migration history, wiping out the rest
$ ./manage.py migrate appname --fake --delete-ghost-migrations

Nếu bạn chỉ làm việc trên máy dev, tôi đã viết một lệnh quản lý thực hiện khá nhiều những gì Dominique đề xuất.

http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

Ngược lại với đề xuất của tác giả phía nam, điều này sẽ KHÔNG HẠI các ứng dụng được cài đặt khác sử dụng phía nam.

Sau đây chỉ khi bạn muốn đặt lại tất cả các ứng dụng. Vui lòng sao lưu tất cả các cơ sở dữ liệu của bạn trước khi làm việc. Ngoài ra, hãy ghi lại tệp phụ thuộc của bạn trong các tệp ban đầu nếu có.

Cho một lần:

(1) find . -type d -name migrations -exec git rm -rf '{}' \;
(2) find . -type d -name migrations -exec rm -rf '{}' \;
(3) ./manage.py schemamigration <APP_NAME> --initial
(4) [GIT COMMIT]

Kiểm tra bootstrapping dự án của bạn trước khi đẩy. Sau đó, đối với mỗi máy cục bộ / từ xa, áp dụng như sau:

(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake

Làm ban đầu (3) cho mỗi ứng dụng bạn muốn tham gia lại. Lưu ý rằng, đặt lại (6) sẽ chỉ xóa lịch sử di chuyển, do đó không gây hại cho thư viện. Di chuyển giả (7) sẽ đưa lại lịch sử di chuyển của bất kỳ ứng dụng bên thứ 3 nào được cài đặt.

xóa tập tin cần thiết khỏi thư mục ứng dụng

đường dẫn cá thể

 cd /usr/local/lib/python2.7/dist-packages/wiki/south_migrations

wiki - là ứng dụng của tôi