Як спростити міграцію в Django 1.7?

Уже є подібні запитання щодо Півдня, але я розпочав свій проект з Django 1.7 і не використовую Південь.

Під час розробки було створено багато міграцій, проте програмне забезпечення ще не розроблено, і не існує бази даних, яку потрібно перенести. Тому я хотів би скинути міграції так, ніби моєю поточною моделлю була оригінальна, і відтворити всі бази даних.

Який рекомендований спосіб зробити це?

EDIT: Станом на Django 1.8 є нова команда з назвою squashmigrations, яка більш-менш вирішує проблему, описану тут.

Я отримав це. Я просто зрозумів це, і це добре.

• Спочатку, щоб очистити таблицю міграцій:

  ./manage.py migrate --fake <app-name> zero

• Видаліть app-name/migrations/папку або вміст.

• Зробіть міграції:

  ./manage.py makemigrations <app-name>

• Нарешті приведіть в порядок свої міграції, не вносячи інших змін до бази даних:

  ./manage.py migrate --fake <app-name>

У версії міграцій Django 1.7 функцію скидання, яка раніше була в Південній Європі, було вилучено на користь нової функціональності для "здушення" ваших міграцій. Це має бути хорошим способом контролювати кількість міграцій.

https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations

Якщо ви все-таки хочете почати все з нуля, я припускаю, що ви все-таки змогли, очистивши таблицю міграцій та видаливши міграції, після чого ви б запустили makemigrationsзнову.

У мене просто була та сама проблема. Ось мій обхідний шлях.

#!/bin/sh
echo "Starting ..."

echo ">> Deleting old migrations"
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc"  -delete


# Optional
echo ">> Deleting database"
find . -name "db.sqlite3" -delete

echo ">> Running manage.py makemigrations"
python manage.py makemigrations

echo ">> Running manage.py migrate"
python manage.py migrate

echo ">> Done"

findКоманда: http://unixhelp.ed.ac.uk/CGI/man-cgi?find

Припускаючи, що це ваша структура проекту,

project_root/
    app1/
        migrations/
    app2/
        migrations/
    ...
    manage.py
    remove_migrations.py

Ви можете запустити скрипт remove_migrations.py з місця, вказаного вище, щоб видалити всі файли міграції.

#remove_migrations.py
"""
Run this file from a Django =1.7 project root. 
Removes all migration files from all apps in a project.
""" 
from unipath import Path

this_file = Path(__file__).absolute()
current_dir = this_file.parent
dir_list = current_dir.listdir()

for paths in dir_list:
    migration_folder = paths.child('migrations')
    if migration_folder.exists():
        list_files = migration_folder.listdir()
        for files in list_files:
            split = files.components()
            if split[-1] != Path('__init__.py'):
                files.remove()

Видалення вручну може втомлювати, якщо у вас є складний проект. Це заощадило мені багато часу. Видалення файлів міграції безпечно. Я робив це вже безліч разів, не стикаючись з жодними проблемами ... поки.

Однак коли я видалив папку міграцій makemigrationsабо migrateне створив папку назад для мене. Сценарій гарантує, що папка міграції з її __init__.pyпостійним ставленням залишатиметься, лише видаляючи файли міграції.

1. Видалити файли: delete_migrations.py (у корені prj):

import os

for root, dirs, files in os.walk(".", topdown=False):
  for name in files:
      if '/migrations' in root and name != '__init__.py':
          os.remove(os.path.join(root, name))

2. DELETE FROM django_migrations Where app in ('app1', 'app2');

3. ./manage.py makemigrations

4. ./manage.py migrate --fake

АБО, ви можете написати міграцію з цього всього

Я пробую різні команди, і деякі відповіді мені допомагають. Тільки ця послідовність у моєму випадку виправила обидві порушені залежності при міграціях у MYAPP та очистила всі минулі міграції, починаючи з нуля.

Перш ніж це зробити, переконайтеся, що база даних уже синхронізована (наприклад, не додайте сюди нове поле Модель або не змінюйте параметри Мета).

rm -Rf MYAPP/migrations/*
python manage.py makemigrations --empty MYAPP
python manage.py makemigrations
python manage.py migrate --fake MYAPP 0002

Де 0002 - номер міграції, повернутий останньою командою makemigrations.

Тепер ви можете знову запускати makemigrations / migrate, оскільки міграція 0002 зберігається, але не відображається у вже синхронізованій базі даних.

Якщо вас не хвилює попередня міграція, як бути з простим видаленням усіх міграцій у каталозі migrations /? Ви почнете послідовність міграції з нуля, взявши свою поточну модель як еталон, ніби ви написали всю модель зараз.

Якщо ви не довіряєте мені, що хочете видалити, спробуйте замість цього відсунути їх.

Це простий спосіб

Перейдіть до кожної програми та видаліть файли міграції.

Потім перейдіть до таблиці django-migrtaions у базі даних та скоротіть її (видаліть усі записи).

Після цього ви можете ще раз створити міграції.

cd до каталогу src cd /path/to/src

видалити каталоги міграції - rm -rf your_app/migrations/

зауважте, що це слід робити для кожного додатка окремо

мігрувати python3.3 manage.py migrate

якщо ви хочете розпочати знову python3.3 manage.py makemigrations your_app

Якщо ви перебуваєте в режимі розробки, і ви просто хочете скинути все (базу даних, міграції тощо), я використовую цей сценарій на основі відповіді Абдельхаміда Ба. Це призведе до стирання таблиць бази даних (Postgres), видалення всіх файлів міграції, повторного запуску міграцій та завантаження моїх початкових елементів:

#!/usr/bin/env bash
echo "This will wipe out the database, delete migration files, make and apply migrations and load the intial fixtures."

while true; do
    read -p "Do you wish to continue?" yn
    case $yn in
        [Yy]* ) make install; break;;
        [Nn]* ) exit;;
        * ) echo "Please answer yes or no.";;
    esac
done

echo ">> Deleting old migrations"
find ../../src -path "*/migrations/*.py" -not -name "__init__.py" -delete

# Optional
echo ">> Deleting database"
psql -U db_user -d db_name -a -f ./reset-db.sql

echo ">> Running manage.py makemigrations and migrate"
./migrations.sh

echo ">> Loading initial fixtures"
./load_initial_fixtures.sh

echo ">> Done"

файл reset-db.sql:

DO $$ DECLARE
    r RECORD;
BEGIN
    -- if the schema you operate on is not "current", you will want to
    -- replace current_schema() in query with 'schematodeletetablesfrom'
    -- *and* update the generate 'DROP...' accordingly.
    FOR r IN (SELECT tablename FROM pg_tables WHERE schemaname = current_schema()) LOOP
        EXECUTE 'DROP TABLE IF EXISTS ' || quote_ident(r.tablename) || ' CASCADE';
    END LOOP;
END $$;

Файл migracija.sh:

#!/usr/bin/env bash
cd ../../src
./manage.py makemigrations
./manage.py migrate

файл load_initial_fixture.sh:

#!/usr/bin/env bash
cd ../../src
./manage.py loaddata ~/path-to-fixture/fixture.json

Тільки не забудьте змінити шляхи на відповідність вашої програми. Я особисто зберігаю ці сценарії в папці з назвою project_root / script / local, а джерела django знаходяться в project_root / src.

Після видалення кожної папки "міграцій" у моєму додатку (вручну) я запустив:

./manage.py dbshell
delete from django_migrations;

Тоді я подумав, що можу просто ./manage.py makemigrationsвідновити їх усіх. Однак змін не виявлено. Потім я спробував вказати по одній програмі за раз: ./manage.py makemigrations foo, ./manage.py makemigrations bar. Однак це призвело до кругових залежностей, які неможливо було вирішити.

Нарешті, я запустив одну команду makemigrations, яка вказала ВСІ мої програми (без певного порядку):

./manage.py makemigrations foo bar bike orange banana etc

Цього разу це спрацювало - кругові залежності вирішувались автоматично (при необхідності створювалися додаткові файли міграції).

Тоді я зміг балотуватися ./manage.py migrate --fakeі повернувся до бізнесу.