Django South - bảng đã tồn tại

Tôi đang cố gắng để bắt đầu với Nam. Tôi đã có một cơ sở dữ liệu hiện có và tôi đã thêm South ( syncdb, schemamigration --initial).

Sau đó, tôi cập nhật models.pyđể thêm một trường và chạy ./manage.py schemamigration myapp --auto. Nó dường như tìm thấy lĩnh vực này và nói rằng tôi có thể áp dụng điều này với ./manage.py migrate myapp. Nhưng, làm điều đó đã gây ra lỗi:

django.db.utils.DatabaseError: table "myapp_tablename" already exists

tablenamelà bảng đầu tiên được liệt kê trong models.py.

Tôi đang chạy Django 1.2, Nam 0.7

vì bạn đã có các bảng được tạo trong cơ sở dữ liệu, bạn chỉ cần chạy di chuyển ban đầu là giả mạo

./manage.py migrate myapp --fake

đảm bảo rằng lược đồ của các mô hình giống như lược đồ của các bảng trong cơ sở dữ liệu.

Mặc dù bảng "myapp_tablename" đã tồn tại lỗi ngừng tăng sau khi tôi đã làm ./manage.py di chuyển myapp --fake, DatabaseError không hiển thị cột nào như vậy: myapp_mymodel.added_field.

Có chính xác cùng một vấn đề!

1.Đầu tiên kiểm tra số di chuyển gây ra điều này. Giả sử nó là: 0010.

2. Bạn cần phải:

./manage.py schemamigration myapp --add-field MyModel.added_field
./manage.py migrate myapp

nếu có nhiều hơn một trường bị thiếu, bạn phải lặp lại nó cho từng trường.

3.Bây giờ bạn hạ cánh với một loạt các lần di chuyển mới, vì vậy hãy xóa các tệp của họ khỏi myapp / di chuyển (0011 và hơn nữa nếu bạn cần thêm nhiều trường).

4.Run này:

./manage.py migrate myapp 0010

Bây giờ hãy thử ./manage.py di chuyển myapp

Nếu nó không thất bại, bạn đã sẵn sàng. Chỉ cần nhân đôi nếu không có trường nào bị thiếu.

BIÊN TẬP:

Vấn đề này cũng có thể xảy ra khi bạn có cơ sở dữ liệu sản xuất mà bạn cài đặt miền Nam và lần đầu tiên, di chuyển ban đầu được tạo trong các bản sao khác sẽ sao chép những gì bạn đã có trong db của mình. Giải pháp dễ dàng hơn nhiều ở đây:

1. Giả mạo di chuyển đầu tiên:

   ./manage di chuyển myapp 0001 - thực hiện

2. Cuộn với phần còn lại của di chuyển:

   ./manage di chuyển myapp

Khi tôi gặp phải lỗi này, nó có một nguyên nhân khác.

Trong trường hợp của tôi, Nam đã bằng cách nào đó để lại trong DB của tôi một bảng trống tạm thời, được sử dụng trong _remake_table () . Có lẽ tôi đã hủy bỏ một cuộc di cư theo cách mà tôi không nên có. Trong mọi trường hợp, từng di cư mới sau này, khi nó được gọi là _remake_table (), đã được ném lỗi sqlite3.pypysqlite2.dbapi2.OperationalError: table "_south_new_myapp_mymodel" already exists, bởi vì nó đã đã tồn tại và không được coi là có.

Một chút _south_new trông kỳ lạ đối với tôi, vì vậy tôi đã duyệt DB của mình, nhìn thấy cái bàn _south_new_myapp_mymodel, gãi đầu, nhìn vào nguồn của Nam , quyết định nó là rác, đánh rơi cái bàn, và tất cả đều ổn.

Nếu bạn gặp sự cố với các mô hình không khớp với cơ sở dữ liệu của mình, như @pielgrzym và bạn muốn tự động di chuyển cơ sở dữ liệu để khớp với tệp mô hình mới nhất (và xóa bất kỳ dữ liệu nào sẽ không được tạo lại bởi đồ đạc trong khi migrate):

manage.py schemamigration myapp --initial
manage.py migrate myapp --fake
manage.py migrate myapp zero
manage.py migrate myapp

Điều này sẽ chỉ xóa và tạo lại các bảng cơ sở dữ liệu tồn tại trong models.pytệp mới nhất của bạn , vì vậy bạn có thể có các bảng rác trong cơ sở dữ liệu của mình từ syncdbs hoặc s trước đó migrate. Để loại bỏ những thứ đó, trước tất cả những lần di chuyển này với:

manage.py sqlclear myapp | manage.py sqlshell

Và nếu điều đó vẫn để lại một số CRUFT nằm trong cơ sở dữ liệu của bạn thì bạn sẽ phải thực hiện inspectdbvà tạomodels.py tệp từ đó (đối với các bảng và ứng dụng mà bạn muốn xóa) trước khi thực hiện sqlclearvà sau đó khôi phục mô hình gốc của bạn trước đó tạo ra sự --initialdi chuyển và di chuyển đến nó Tất cả điều này để tránh gây rối với hương vị đặc biệt của SQL mà cơ sở dữ liệu của bạn cần.

Perform these steps in order may help you:

1) python Manage.py schemamigration apps.appname --initial

Bước trên tạo thư mục di chuyển như mặc định.

2) python Manage.txt di chuyển apps.appname --fake

tạo ra một di chuyển giả mạo.

3) python Manage.py schemamigration apps.appname --auto

Sau đó, bạn có thể thêm các trường như bạn muốn và thực hiện lệnh trên.

4) python Manage.txt di chuyển apps.appname

Nếu bạn có cơ sở dữ liệu và ứng dụng hiện có, bạn có thể sử dụng lệnh chuyển đổi phía nam

./manage.py convert_to_south myapp

Điều này phải được áp dụng trước khi bạn thực hiện bất kỳ thay đổi nào đối với những gì đã có trong cơ sở dữ liệu.

Lệnh convert_to_south chỉ hoạt động hoàn toàn trên máy đầu tiên bạn chạy. Khi bạn đã cam kết các lần di chuyển ban đầu được thực hiện vào VCS của mình, bạn sẽ phải chạy ./manage.py migrate myapp 0001 --faketrên mọi máy có bản sao của cơ sở mã (trước tiên hãy đảm bảo rằng chúng được cập nhật với các mô hình và lược đồ). ref: http://south.readthedocs.org/en/latest/convertinganapp.html

Là giải pháp tạm thời, bạn có thể nhận xét việc tạo Bảng trong tập lệnh di chuyển.

class Migration(migrations.Migration):

    dependencies = [
        (...)
    ]

    operations = [
        #migrations.CreateModel(
        #    name='TABLE',
        #    fields=[
        #            ....
        #            ....
        #    ],
        #),
        ....
        ....

Hoặc là

Nếu bảng hiện có không chứa hàng (trống), thì hãy xem xét xóa bảng như bên dưới. (Khắc phục này chỉ được khuyến nghị nếu bảng không chứa hàng) . Đồng thời đảm bảo thao tác này trước thao tác createModel.

class Migration(migrations.Migration):

    dependencies = [
        (...),
    ]

    operations = [
        migrations.RunSQL("DROP TABLE myapp_tablename;")
    ]

Thêm một giải pháp (có thể là giải pháp tạm thời).

$ python manage.py sqlmigrate APP_NAME MIGRATION_NAME

ví dụ.,.

$ python manage.py sqlmigrate users 0029_auto_20170310_1117

Điều này sẽ liệt kê tất cả các di chuyển trong các truy vấn sql thô. Bạn có thể chọn các truy vấn mà bạn muốn chạy để tránh phần tạo ra bảng hiện có