migrations force createsuperuser cancel django migration django-south django-migrations

force - Cómo restablecer las migraciones en Django 1.7



no migrations to apply django (4)

(Sé que hay un título igual a este, pero la pregunta es diferente).

Logré que las migraciones de la máquina de desarrollo y las migraciones de producción no estuvieran sincronizadas.

Tengo una aplicación Django que estaba usando South. Tenía mi propio flujo de trabajo que funcionaba bien (probablemente no era la forma correcta de hacer las cosas, pero no tuve problemas con eso).

Básicamente tengo un script que copia el volcado de la base de datos de producción a mi máquina de desarrollo. También copió los archivos de migración. De esa manera los dos estaban sincronizados, y yo podía ejecutar los comandos del Sur de manera normal.

Ahora me actualicé a 1.7 y comencé a usar las migraciones. Cuando uso mi flujo de trabajo anterior (copiar volcado de base de datos y archivos de migración de producción), no se detectan cambios en mi máquina de desarrollo.

He leído el documento de migraciones y veo que la forma correcta de usarlo es

  1. ejecutar "realizar migraciones" y "migrar" en mi máquina de desarrollo.
  2. ejecute "migrar" en mi máquina devlopemnt para realizar los cambios en la base de datos
  3. Copia los cambios, incluidos los archivos de migración.
  4. ejecutar "migrar" en la máquina de producción. (sin el paso "makemigrations")

De todas formas. Todo es un desastre ahora. Me gustaría "restablecer" mis migraciones y empezar de cero, haciendo las cosas correctamente de ahora en adelante.

¿Que necesito hacer?

  1. ¿Eliminar los contenidos de la tabla de migración (en ambas máquinas)?
  2. ¿Eliminar los contenidos de la carpeta de migración? (Incluyendo el archivo init .py).
  3. Inicie las migraciones según la documentación para una nueva.

¿Me he perdido algo? ¿Hay alguna razón por la que copiar todo desde la producción (base de datos y archivos de migración) no detecte ningún cambio en mi máquina de desarrollo después?


1)

Comience por eliminar su base de datos usando el lenguaje SQL si está usando un sistema de base de datos como Posgres o MySQL y tiene una base de datos con el nombre mydb

delete mydb;

2)

A continuación, debe revisar todas las carpetas de migración para cada aplicación que pertenezca a su proyecto y eliminar los archivos de migración, excepto init.py

Si está utilizando un terminal en Linux / MAC, puede automatizar este tedioso fácilmente. Por ejemplo

find . -path "*/migrations/*.py" -not -name "__init__.py" -delete find . -path "*/migrations/*.pyc" -delete

3)

Lo siguiente que debes hacer es ejecutar el comando de dos migraciones que normalmente invocas cuando estás sincronizando tus modelos con una nueva base de datos con Django.

python manage.py makemigrations python manage.py migrate

Asegúrese de que ha creado una nueva base de datos después de eliminar la antigua si está utilizando cualquier sistema de base de datos que no sea sqlite.

Cuando su aplicación está en producción porque no puede eliminar su base de datos, ¿cómo puede restablecer las migraciones en este caso?

Simplemente necesitamos mantener la base de datos mientras nos deshacemos del historial de migraciones. A continuación le indicamos cómo hacerlo en pasos detallados:

1)

Primero revise cada aplicación y desactive su historial de migraciones emitiendo el siguiente comando

python manage.py migrate --fake myApp zero

Django no aplicará ninguna migración anterior para la aplicación específica (myApp)

2)

A continuación, debe eliminar realmente el archivo de migraciones, por lo que deberá volver a revisar cada carpeta de migraciones de aplicaciones y eliminarlas, excepto init.py. Simplemente use el siguiente script en cualquier sistema operativo basado en Unix. Para Windows, puede usar el poder línea de comando. Debería ser similar a Unix, pero sinceramente no uso Windows ni netier power bash

find . -path "*/migrations/*.py" -not -name "__init__.py" -delete find . -path "*/migrations/*.pyc" -delete

Puedes verificar fácilmente tus migraciones usando:

python manage.py showmigrations

3)

A continuación necesitamos crear las migraciones de nuevo, así que solo ejecuta

python manage.py makemigrations

PERO no olvide que la base de datos todavía tiene tablas que pertenecen a las migraciones iniciales, así que lo que debemos hacer es migrar nuestra base de datos y al mismo tiempo simular las migraciones iniciales que puede hacer simplemente ejecutando

python manage.py migrate --fake-initial


Solo haría lo siguiente en ambos entornos (siempre que el código sea el mismo)

  1. Borra tu carpeta de migraciones
  2. ELIMINAR DE django_migrations WHERE app = <your app name> . Alternativamente, puedes truncar esta tabla.
  3. python manage.py makemigrations
  4. python manage.py migrate --fake

Después de esto, todos sus cambios deberían ser detectados en todos los entornos.


Una pequeña variación en la respuesta de Harshil:

$ manage.py migrate --fake <appname> zero $ rm -rf migrations $ manage.py makemigrations <appname> $ manage.py migrate --fake <appname>

Esta voluntad ...

  • pretende restituir todas tus migraciones sin tocar las tablas reales de la aplicación
  • elimine sus scripts de migración existentes para la aplicación
  • Crea una nueva migración inicial para la aplicación.
  • Falsificar una migración a la migración inicial de la aplicación.

correr

python manage.py migrate your_app zero

Esto eliminará todas las tablas de your_app

Si lo desea, ya que dijo que desea comenzar de nuevo, puede eliminar su carpeta de migraciones, o quizás cambiar el nombre de la carpeta, crear una nueva carpeta de migraciones y ejecutar

python manage.py makemigrations your_app python manage.py migrate your_app

Al igual que en el sur, siempre puedes ir y venir ...

# Go to the first migration python manage.py migrate your_app 0001 # Go to the third migration python manage.py migrate your_app 0003

Entonces, imagine que su cuarta migración es un desastre ... siempre puede migrar a la tercera, eliminar el cuarto archivo de migración y volver a hacerlo.

Nota:

Esta es una de las razones por las que sus modelos deberían estar en diferentes aplicaciones. Digamos que tienes 2 modelos: Usuario y Nota. Es una buena práctica crear 2 aplicaciones: usuarios y notas para que las migraciones sean independientes entre sí.

Intenta no usar una sola aplicación para todos tus modelos.