migraciones django – flujo de trabajo con múltiples twigs dev

Tengo curiosidad de cómo otros desarrolladores de django administran múltiples twigs de código (en git por ejemplo) con migraciones.

Mi problema es el siguiente: – tenemos varias twigs de características en git, algunas de ellas con migraciones django (algunas de ellas alteran campos, o las eliminan por completo) – cuando cambio twigs (con git checkout some_other_branch ) la database no refleja siempre el nuevo código, así que me encuentro con errores "aleatorios", donde ya no existe una columna de tabla db, etc.

En este momento, simplemente dejo caer el file db y lo vuelvo a crear, pero eso significa que tengo que volver a crear un montón de datos ficticios para reiniciar el trabajo. Puedo usar accesorios, pero requiere hacer un seguimiento de qué datos van a parar, es un poco complicado.

¿Hay una forma buena / limpia de manejar este caso de uso? Estoy pensando en que un script de git hook post-checkout podría ejecutar las migraciones necesarias, pero ni siquiera sé si las reversiones de migration son posibles.

La reversión de migraciones es posible y, por lo general, django maneja automáticamente.

Considerando el siguiente model:

 class MyModel(models.Model): pass 

Si ejecuta python manage.py makemigrations myapp , generará el script de migration inicial. A continuación, puede ejecutar python manage.py migrate myapp 0001 para aplicar esta migration inicial.

Si después de eso agrega un campo a su model:

 class MyModel(models.Model): my_field = models.CharField() 

Luego, regenere una nueva migration y, a continuación, aplíquela; aún puede volver al estado inicial. Simplemente ejecute python manage.py migrate myapp 0001 y el ORM retrocederá, eliminando el nuevo campo.

Es más complicado cuando se trata de migraciones de datos, porque tiene que escribir el código hacia adelante y hacia atrás. Considerando una migration vacía creada a través de python manage.py makemigrations myapp --empty , terminará con algo como:

 # -*- coding: utf-8 -*- from __future__ import unicode_literals from django.db import models, migrations def forward(apps, schema_editor): # load some data MyModel = apps.get_model('myapp', 'MyModel') while condition: instance = MyModel() instance.save() def backward(apps, schema_editor): # delete previously loaded data MyModel = apps.get_model('myapp', 'MyModel') while condition: instance = MyModel.objects.get(myargs) instance.delete() class Migration(migrations.Migration): dependencies = [ ('myapp', '0003_auto_20150918_1153'), ] operations = [ migrations.RunPython(forward, backward), ] 

Para las migraciones de carga de datos puros, generalmente no necesita la migration hacia atrás. Pero cuando modifica el esquema y actualiza las filas existentes,
(como convertir todos los valores en una columna a slug), generalmente tendrá que escribir el paso hacia atrás.

En nuestro equipo, tratamos de evitar trabajar en los mismos models al mismo time para evitar colisiones. Si no es posible, y se crean dos migraciones con el mismo número (por ejemplo, 0002), aún puede cambiar el nombre de una de ellas para cambiar el order en que se aplicarán (también recuerde actualizar el atributo de dependencies en la class de migration a tu nuevo pedido).

Si termina trabajando en los mismos campos del model al mismo time en diferentes funciones, seguirá teniendo problemas, pero puede significar que estas características están relacionadas y deben manejarse juntas en una sola sucursal.

Para la parte git-hooks, probablemente sea posible escribir algo, suponiendo que estás en la twig mybranch y quieres mybranch vistazo a otra function branch myfeature :

  1. Justo antes de cambiar, vuelcas la list de migraciones aplicadas actualmente en un file temporal mybranch_database_state.txt
  2. Luego, aplica myfeature twig myfeature , si hay alguna
  3. Luego, cuando mybranch , vuelves a aplicar tu estado anterior de la database mirando el file de volcado.

Sin embargo, me parece un poco hackish, y probablemente sería realmente difícil manejar correctamente todos los escenarios: rebase, fusión, selección de cerezas, etc.

Manejo de los conflictos de migraciones cuando ocurren me parece más fácil.

No tengo una buena solución para esto, pero siento el dolor.

Un enlace posterior a la salida será demasiado tarde. Si está en la twig A y echa un vistazo a la twig B, y B tiene less migraciones que A, la información de restitución está solo en A y debe ejecutarse antes de finalizar la compra.

Llegué a este problema al saltar entre varios commits tratando de localizar el origen de un error. Nuestra database (incluso en el ajuste de desarrollo) es enorme, por lo que dejar de usarlo y recrearlo no es práctico.

Me estoy imaginando un contenedor para git-checkout que:

  1. Toma nota de la migration más reciente para cada uno de sus INSTALLED_APPS
  2. Busca en la twig solicitada y toma nota de las migraciones más recientes allí
  3. Para cada aplicación donde las migraciones en el n. ° 1 están más adelantadas que en el n. ° 2, migre nuevamente a la migration más alta en n. ° 2
  4. Mira la nueva sucursal
  5. Para cada aplicación donde las migraciones en el n. ° 2 estuvieron por delante del n. ° 1, migre hacia adelante

¡Una simple cuestión de progtwigción!