2010-10-23 22 views
18

Tengo una aplicación de Django. Tengo archivos de dispositivos .json que contienen datos de prueba, con pruebas unitarias que usan los datos para confirmar que la aplicación funciona correctamente. También uso South para migrar mi base de datos.Migración de accesorios Django?

Después de migrar algunas bases de datos, mis dispositivos no están actualizados, porque la base de datos migró, agregando una nueva columna de base de datos, por ejemplo, y los datos del dispositivo no tienen esa columna, ya que fue capturada antes del base de datos cambiada.

¿Cuál es la mejor manera de mover mis dispositivos hacia adelante mientras migro mi base de datos?

Respuesta

12

Aquí está el proceso utilicé:

  1. retroceder el código para la revisión que creó el accesorio en el primer lugar. Por ejemplo: svn up -r12345.

  2. Vaciar la base de datos, a continuación, crear con manage.py syncdb --noinput --migrate

  3. carga el aparato con manage.py loaddata my_fixture.json

  4. rollo del código con interés ahora, con svn up

  5. Migración de la base de datos con manage.py migrate

  6. Vuelque los datos con manage.py dumpdata --indent=2 myapp >my_fixture.json

Tenga en cuenta que debe tener cuidado al elegir la revisión pasada a la que desea retroceder. En mi caso, tuve algunas correcciones recientes que debían estar en su lugar, así que tuve que escoger y elegir directorios para volver a las revisiones específicas. Tedioso, pero mejor que editar manualmente un archivo JSON de 9,000 líneas.

Además, en el paso 6, asegúrese de volcar el conjunto correcto de aplicaciones.

En el futuro, mientras escribo migraciones, puedo seguir estos pasos para mantener todos los dispositivos actualizados.

+1

Estoy en un punto similar aunque recién estoy empezando, buscando tomar un enfoque de prueba primero. Todo el proceso 'vaciar la base de datos, cargar el accesorio de prueba, migrar, volcar el accesorio de prueba' va a matar el flujo de trabajo. Con suerte, otros sugerirán (o codificarán ;-)) una solución más elegante. –

+0

tenga en cuenta que si retrocede primero, termina con los accesorios de ese momento. Lo que significa que cualquier cambio en el medio será descartado. si algo se actualizó manualmente, se cancelará, por lo que tiendo a copiar los accesorios en otro lugar, luego retroceder, cargar los accesorios movidos, avanzar, migrar, etc. – MrE

-2

¿Cuál es la mejor manera de mover mis dispositivos hacia adelante cuando migro mi base de datos?

Es demasiado tarde.

Al migrar su base de datos necesita loaddata y dumpdata.

Uno deja de funcionar, es demasiado tarde.

Una posible alternativa es escribir un script corto para cargar los dispositivos JSON en la memoria, y luego construir objetos de base de datos "manualmente".

with open("somefile.json", "r") as data: 
    for obj in json.load(data): 
     if obj['model'] == 'someapp.somemodel': 
      SomeNewModel.objects.create( 
       field = obj['fields']['element'] 
       ... 
       ) 

Con algo por el estilo, que podría ser capaz de construir una base de datos con sus accesorios de esquema y heredados actuales.

+3

Gracias, pero no creo que sea demasiado tarde. Siempre puedo retrotraer mi código y/o mi base de datos a un estado anterior, por lo que estoy seguro de que puedo volver al camino correcto. ¿Podría darnos un poco más de detalles sobre cómo funcionaría loaddata/dumpdata? Supongo que hay una migración en el medio, por ejemplo. Pero si mi accesorio es solo para una aplicación, ¿cómo sabrá South para aplicar la migración? –

+0

@Ned Batchelder: "Siempre puedo retrotraer mi código y/o mi base de datos a un estado anterior," Si bien es cierto, eso es demasiado complejo. Es realmente muy tarde. Lea esto para loaddata y dumpdata: http://docs.djangoproject.com/en/dev/ref/django-admin/. –

+3

Sería una característica clave para South si fuera a migrar accesorios también. –

1

¿Por qué no puede simplemente crear un nuevo archivo .json desde su db. Esto es lo que hago cuando necesito crear un nuevo accesorio.

python manage.py dumpdata <your_app> auth > test_data.json 
+0

Porque mis datos de prueba son una muestra controlada, no simplemente la última instantánea de mi base de datos de producción. –

Cuestiones relacionadas