Las migraciones de Django 1.7 no recrearán una tabla caída, ¿por qué?

Usando las migraciones de Django 1.7.

Accidentalmente dejé caer una mesa en mi base de datos. Asumí que al ejecutar la migración nuevamente, esto recrearía la tabla pero no, Django dice “No hay migraciones para aplicar”.

¿Cómo consigo Django para recrear la tabla?

He corrido:

> makemigrations - No changes detected > migrate - No migrations to apply. 

He intentado realizar un cambio en el modelo y ejecutar una nueva migración y simplemente dice que “la Tabla ‘x.test_customer’ no existe”, lo cual es correcto, pero lo que esperaba era que recreara la tabla.

Las migraciones comprueban las diferencias en sus modelos y luego las traducen en acciones, que se traducen a SQL. No sincroniza automáticamente el esquema de base de datos con sus modelos, y no tiene forma de saber si ha abandonado una tabla (no sabe acerca de los cambios manuales porque, bueno, no debe hacer cambios manuales. Ese es el punto)

¿La respuesta? un cambio manual requiere una migración manual también . Lo que debe hacer es simplemente escribir su propia migración e indicar manualmente a South que vuelva a construir la tabla. No es muy difícil, los documentos lo hacen bastante fácil. Solo haz algo como esto:

 from django.db import migrations, models class Migration(migrations.Migration): operations = [ migrations.CreateModel("Foo"), migrations.AddField("Foo", "bar", models.IntegerField(default=0)) ] 

Probablemente pueda buscar en el primer archivo de migración (el que hizo el modelo en primer lugar) y copiar y pegar casi todo. Entonces todo lo que tienes que hacer es ejecutar la migración como siempre lo haces.

Ve a tu base de datos y encuentra la tabla django_migrations . Eliminar todas las filas que tienen app es igual a su nombre de aplicación.

Entonces hacer una makemigrations y migrate funcionará.

Otra solución que he encontrado y funciona perfectamente:

En django 1.7:

  1. Borra tu carpeta de migraciones

  2. En la base de datos: DELETE FROM django_migrations WHERE app = 'app_name' .

    Alternativamente, usted podría simplemente truncar esta tabla.

  3. python manage.py makemigrations

  4. python manage.py migrate --fake

En Django 1.9.5:

  1. Borra tu carpeta de migraciones
  2. En la base de datos: DELETE FROM django_migrations WHERE app = 'app_name' .

    Alternativamente, usted podría simplemente truncar esta tabla.

  3. python manage.py makemigrations app_name

  4. python manage.py migrate

¡Esto funciona al 100% para mí!

De hecho, encontré una manera más fácil de hacer esto Finges que haces un rollback de lo que no existe, luego vuelves a migrar. Si su migración 0005 fue la que crea la tabla:

 python manage.py migrate myapp --fake 0004 python manage.py migrate myapp 

Debería ser bueno después de eso!

Si necesitas saltarte los posteriores, haz esto:

 python manage.py migrate myapp --fake 0004 python manage.py migrate myapp 0005 python manage.py migrate myapp --fake 

Debería ser bueno después de eso!

Descargo de responsabilidad completo, esta es una operación destructiva en algunos casos, y la uso principalmente para volver a migrar partes del sistema sin afectar la base de datos.

¿Has intentado hacerlo a través de la tabla django_migrations ? Simplemente elimine las filas que se asignan a la etiqueta de la aplicación y los nombres de migración en cuestión y elimine esas filas.

 +----+-----------------------+----------------------------------------------------------+---------------------+ | id | app | name | applied | +----+-----------------------+----------------------------------------------------------+---------------------+ | 1 | contenttypes | 0001_initial | 2015-03-07 16:32 | | 30 | homepage | 0001_initial | 2015-04-02 13:30:44 | | 31 | homepage | 0002_auto_20150408_1751 | 2015-04-08 12:24:55 | | 32 | homepage | 0003_remove_mappinghomepagemoduleinventory_inventoryinfo | 2015-04-09 08:09:59 | +----+-----------------------+----------------------------------------------------------+---------------------+ 

Así que ahora, si quiero eliminar la homepage , solo puedo eliminar las filas 30, 31, 32.

Por supuesto, ya que también eliminó las tablas, también tendría que cambiar django_content_type :

 +----+----------------------------------------+-----------------------+--------------------------------------+ | id | name | app_label | model | +----+----------------------------------------+-----------------------+--------------------------------------+ | 1 | content type | contenttypes | contenttype | | 2 | session | sessions | session | | 3 | site | sites | site | | 92 | master_homepagemodule_extrafields | homepage | masterhomepagemoduleextrafields | | 93 | mapping_homepagemodule_inventory | homepage | mappinghomepagemoduleinventory | | 94 | master_homepagemodule_inventoryfields | homepage | masterhomepagemoduleinventoryfields | | 95 | mapping_homepagemodule_inventoryfields | homepage | mappinghomepagemoduleinventoryfields | | 96 | master_homepagemodule | homepage | masterhomepagemodule | | 97 | mapping_homepagemodule_extrafields | homepage | mappinghomepagemoduleextrafields | +----+----------------------------------------+-----------------------+--------------------------------------+ 

Así que ahora tendría que eliminar las tablas que necesita para volver a migrar las necesidades al eliminar las filas de esas tablas.

He usado esto cuando el tiempo era escaso y necesitábamos una solución rápida y sucia, o cuando jugábamos en desarrollo.
Espero que te ayude también!

La forma más sencilla de hacer esto en django> = 1.9 es ejecutar lo siguiente:

 ./manage.py migrate app_name zero 

Eso eliminará tus tablas y revertirá todas las migraciones.

OK, así que lo que hice fue no meterme con las migraciones. Parece que me meto en problemas de vez en cuando con las migraciones. Y en este caso, intentar reproducir las migraciones no me llevó a ningún lado. Podría no haber ayudado a que hubiera algunas migraciones de South-vintage, así como las nuevas 1.7 cosas.

medio ambiente: postgres 9.3

Básicamente, restauré una copia de seguridad antigua de mi base de datos en una base de datos vacía . Luego saqué el objective de restauración en la utilidad de administración de postgres y copié / pegué las tablas de creación de la descripción de cada tabla (solo me faltaban 4). Cambié a mi base de datos de prueba y la ejecuté en la utilidad sql de pg.

No lo sé, no creo que no sea razonable eliminar una tabla manualmente si tiene problemas con ella (me pareció que la secuencia de mi campo de identificación no estaba funcionando), siempre que pueda vivir perdiendo sus datos. Las migraciones deben ser resistentes en ese caso de uso.

En mi caso en django 2.0.2 para recrear la tabla caída, necesitaba comentar mis modelos en myapp y luego migrar con --fake y descomentar mis modelos y migrar sin --fake Un poco diferente de la respuesta de raul:

  1. Borre sus archivos de migración en la aplicación deseada
  2. Gracias a raul answer: En la base de datos: DELETE FROM django_migrations WHERE app = 'app_name' .
  3. comente los códigos en models.py y todos estos modelos de uso en views , signals y etc. (para evitar errores).
  4. python manage.py makemigrations YOUR_APP_NAME
  5. python manage.py migrate --fake
  6. des-comenta lo que comentaste en el paso 3
  7. python manage.py makemigrations YOUR_APP_NAME
  8. migrar sin –fake : python manage.py migrate

Esto debería resolver algún problema de los usuarios.

Solo encontré esto mientras construía una pequeña aplicación aprendiendo django. Quería crear una columna no nula para una tabla existente. Había tres pasos:

  1. dejar la mesa
  2. Eliminar el registro en django_migrations.
  3. Eliminar la migración de la tabla en cuestión.
    • si ejecuta “makthigrations de python manage.py” antes de este paso, seguirá obteniendo el mensaje “Está intentando agregar un campo que no puede contener nulos”

Para una aplicación real, deberías proporcionar un valor predeterminado, como han señalado otros.