python - migrations - Las migraciones de Django 1.7 no recrearán una tabla caída, ¿por qué?
makemigrations django (8)
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.
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 las 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!
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:
- Borre sus archivos de migración en la aplicación deseada
- Gracias a raul answer: En la base de datos:
DELETE FROM django_migrations WHERE app = ''app_name''
. - comente los códigos en
models.py
y todos estos modelos de uso enviews
,signals
y etc. (para evitar errores). -
python manage.py makemigrations YOUR_APP_NAME
-
python manage.py migrate --fake
- des-comenta lo que comentaste en el paso 3
-
python manage.py makemigrations YOUR_APP_NAME
- migrar sin --fake :
python manage.py migrate
Esto debería resolver algún problema de los usuarios.
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.
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 se supone que haga 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 y decirle al sur manualmente 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 tiene que hacer es ejecutar la migración como siempre lo hace.
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 ninguna parte. 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 objetivo 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 quedaban 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.
Otra solución que he encontrado y funciona perfectamente:
En django 1.7:
Borra tu carpeta de migraciones
En la base de datos:
DELETE FROM django_migrations WHERE app = ''app_name''
.Alternativamente, usted podría simplemente truncar esta tabla.
python manage.py makemigrations
python manage.py migrate --fake
En Django 1.9.5:
- Borra tu carpeta de migraciones
En la base de datos:
DELETE FROM django_migrations WHERE app = ''app_name''
.Alternativamente, usted podría simplemente truncar esta tabla.
python manage.py makemigrations app_name
python manage.py migrate
¡Esto funciona al 100% para mí!
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á.
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.
Usé 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!