sirven que para migrations migraciones migracion makemigrations las forzar force eliminar borrar django django-models merge django-south rebase

que - no migrations to apply django



Mantenimiento de las migraciones del sur en las horquillas de Django (1)

Estoy trabajando en un proyecto Django bastante complejo (más de 50 modelos) con una lógica complicada (muchos flujos de trabajo, vistas, señales, API, tareas en segundo plano, etc.). Llamemos a este project-base . Actualmente usa las migraciones Django 1.6 + South y bastantes otras aplicaciones de terceros.

Ahora, uno de los requisitos es crear una bifurcación de este proyecto que agregará algunos campos / modelos aquí y allá y alguna lógica adicional además de eso. Llamemos a este project-fork . La mayor parte del trabajo adicional estará en la parte superior de los modelos existentes, pero también habrá algunos nuevos.

A medida que se desarrolla la project-base , queremos que estas características también entren en el project-fork (muy parecido a una rebase / fusión en git-land). Los cambios adicionales en project-fork no se fusionarán de nuevo en project-base .

¿Cuál podría ser la mejor manera posible de lograr esto? Estas son algunas de mis ideas:

  1. Use South Merges en project-fork para mantenerlo actualizado con los últimos cambios desde el project-base , como se explica aquí . Utilice señales y cualquier otro medio necesario para mantener la nueva lógica del project-fork más unida posible para evitar posibles conflictos.

  2. No modifique NINGUNO de los modelos originales OneToOneField project-base y, en su lugar, cree nuevos modelos en diferentes aplicaciones que OneToOneField referencia a los modelos antiguos (es decir, que usen OneToOneField ). La lógica extra podría terminar en las aplicaciones antiguas y / o nuevas.

  3. tu idea aquí por favor :)

Me gustaría ir con la opción 1, ya que parece menos complejo en su conjunto, pero podría exponer un mayor riesgo. Así es como lo vería suceder:

Migraciones en project-base a project-base :

  • 0001_project_base_one
  • 0002_project_base_two
  • 0003_project_base_three

Migraciones en project-fork :

  • 0001_project_base_one
  • 0002_project_fork_one

Después de la fusión, las migraciones se verían así:

  • 0001_project_base_one
  • 0002_project_base_two
  • 0002_project_fork_one
  • 0003_project_base_three
  • 0004_project_fork_merge_noop (agregado para combinar los cambios de ambos proyectos)

¿Hay algún inconveniente usando este enfoque? ¿Hay una mejor manera?

Gracias por tu tiempo.

Flujo de trabajo oficial del sur:

La recomendación oficial del Sur es intentar con la bandera de --merge : http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow

Obviamente, esto no funcionará en todos los casos, según mi experiencia, en la mayoría de los casos funciona.

Escollos:

  • Múltiples cambios en el mismo modelo aún pueden romperse
  • Los cambios duplicados pueden romper las cosas

La "mejor" manera suele ser evitar cambios simultáneos en los mismos modelos, la manera más fácil de hacerlo es reduciendo la ventana de error tanto como sea posible.

Mis flujos de trabajo personales en estos casos:

Con tenedores pequeños donde los cambios del modelo son obvios desde el principio:

  1. Discuta qué cambios de modelo deberán realizarse para la horquilla
  2. Aplique esos cambios a ambas / todas las ramas lo más rápido posible para evitar conflictos
  3. Trabaja en el tenedor ...
  4. Combina la horquilla que no da nuevas migraciones

Con tenedores grandes donde los cambios no siempre son obvios y / o cambiarán de nuevo:

  1. Haz las cosas normales de fork y desarrollo mientras intentas mantenerte al día con la última rama master / develop tanto como sea posible
  2. Antes de volver a fusionarse, deseche todas las migraciones de esquema en la bifurcación
  3. Fusionar todos los cambios del maestro / desarrollar
  4. Recrear todos los cambios de esquema necesarios
  5. Fusionar para desarrollar / dominar