Modificación de tablas de bases de datos en Django

Question

Estoy considerando usar Django para un proyecto que estoy comenzando (para tu información, un juego basado en navegador) y una de las características que más me gusta es usar syncdb para crear automáticamente las tablas de la base de datos basadas en los modelos de Django que defino (una característica que parece que no puedo encontrar en ningún otro marco).Ya estaba pensando que esto era demasiado bueno para ser verdad cuando vi esto en el documentación:

Syncdb no alterará las tablas existentes

syncdb solo creará tablas para los modelos que aún no se han instalado.Nunca emitirá declaraciones ALTER TABLE para hacer coincidir los cambios realizados en una clase de modelo después de la instalación.Los cambios en las clases de modelos y esquemas de bases de datos a menudo implican algún tipo de ambigüedad y, en esos casos, Django tendría que adivinar los cambios correctos a realizar.Existe el riesgo de que se pierdan datos críticos en el proceso.

Si ha realizado cambios en un modelo y desea modificar las tablas de la base de datos para que coincidan, utilice el comando sql para mostrar la nueva estructura SQL y compararla con su esquema de tabla existente para resolver los cambios.

Parece que la modificación de las tablas existentes tendrá que hacerse "a mano".

Lo que me gustaría saber es la mejor manera de hacer esto.Se me ocurren dos soluciones:

• Como sugiere la documentación, realice los cambios manualmente en la base de datos;
• Haga una copia de seguridad de la base de datos, bórrela, cree las tablas nuevamente (con syncdb, ya que ahora está creando las tablas desde cero) e importe los datos respaldados (esto puede llevar demasiado tiempo si la base de datos es grande)

¿Algunas ideas?

Answer 1

Como se señaló en otras respuestas al mismo tema, asegúrese de mirar el Panel de evolución del esquema DjangoCon 2008 en Youtube.

Además, dos nuevos proyectos en el mapa: migraciones simples y Migratorio.

Answer 2

Realizar manualmente los cambios de SQL y volcar/recargar son opciones, pero es posible que también desees consultar algunos de los paquetes de evolución de esquemas para Django.Las opciones más maduras son evolución-django y Sur.

EDITAR:Y oye, aquí viene migraciones.

ACTUALIZAR:Dado que esta respuesta fue escrita originalmente, evolución-django y migraciones han cesado el desarrollo activo y Sur se ha convertido en el estándar de facto para la migración de esquemas en Django.Es posible que partes de South incluso se integren en Django en una o dos próximas versiones.

ACTUALIZAR:En Django 1.7+ se incluye un marco de migraciones de esquemas basado en South (y escrito por Andrew Godwin, autor de South).

Answer 3

Una buena manera de hacerlo es a través de accesorios, particularmente los initial_data accesorios.

Un dispositivo es una colección de archivos que contienen el contenido serializado de la base de datos.Entonces, es como tener una copia de seguridad de la base de datos, pero como es algo de lo que Django es consciente, es más fácil de usar y tendrá beneficios adicionales cuando hagas cosas como pruebas unitarias.

Puede crear un dispositivo a partir de los datos actualmente en su base de datos usando django-admin.py dumpdata.Por defecto los datos están en formato JSON, pero hay otras opciones disponibles como XML.Un buen lugar para guardar accesorios es un fixtures subdirectorio de los directorios de su aplicación.

Puedes cargar un fixture usando django-admin.py loaddata pero lo más importante es que si tu aparato tiene un nombre como initial_data.json se cargará automáticamente cuando hagas un syncdb, ahorrándose la molestia de importarlo usted mismo.

Otro beneficio es que cuando corres manage.py test Para ejecutar sus pruebas unitarias, la base de datos de prueba temporal también tendrá cargado el accesorio de datos inicial.

Por supuesto, esto funcionará cuando agregue atributos a modelos y columnas a la base de datos.Si elimina una columna de la base de datos, deberá actualizar su dispositivo para eliminar los datos de esa columna, lo que podría no ser sencillo.

Esto funciona mejor cuando se realizan muchos pequeños cambios en la base de datos durante el desarrollo.Para actualizar bases de datos de producción, un script SQL generado manualmente a menudo puede funcionar mejor.

Answer 4

He estado usando django-evolution.Las advertencias incluyen:

• Sus sugestiones automáticas han estado uniformemente podridas;y
• Su función de huella digital devuelve diferentes valores para la misma base de datos en diferentes plataformas.

Dicho esto, encuentro la costumbre. schema_evolution.py acercarse a la mano.Para solucionar el problema de las huellas dactilares, sugiero un código como:

BEFORE = 'fv1:-436177719' # first fingerprint
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486'

fingerprints = [
    BEFORE, AFTER,
    BEFORE64, AFTER64,
    ]

CHANGESQL = """
    /* put your SQL code to make the changes here */
    """

evolutions = [
    ((BEFORE, AFTER), CHANGESQL),
    ((BEFORE64, AFTER64), CHANGESQL)
    ]

Si tuviera más huellas digitales y cambios, lo refactorizaría.Hasta entonces, hacerlo más limpio sería robarle tiempo de desarrollo a otra cosa.

EDITAR: Dado que de todos modos estoy construyendo mis cambios manualmente, intentaré migraciones La próxima vez.

Answer 5

extensiones-de-comando-django es una biblioteca de Django que proporciona algunos comandos adicionales para administrar.py.Uno de ellos es sqldiff, que debería brindarle el SQL necesario para actualizar a su nuevo modelo.Sin embargo, está catalogado como "muy experimental".

Answer 6

Hasta ahora en mi empresa hemos utilizado el enfoque manual.Lo que funcione mejor para usted depende en gran medida de su estilo de desarrollo.

Por lo general, no tenemos tantos cambios de esquema en los sistemas de producción ni implementaciones algo formalizadas desde los servidores de desarrollo a los de producción.Cada vez que implementamos (10 a 20 veces al año), hacemos una comparación completa de la rama de producción actual y próxima, revisando todo el código y tomando nota de lo que se debe cambiar en el servidor de producción.Los cambios requeridos pueden ser dependencias adicionales, cambios en el archivo de configuración y cambios en la base de datos.

Esto funciona muy bien para nosotros.Tenerlo todo automatizado es una visión de nicho, pero demasiado difícil para nosotros: tal vez podríamos gestionar las migraciones, pero aún necesitaríamos manejar bibliotecas, servidores o dependencias adicionales.

Answer 7

Django 1.7 (actualmente en desarrollo) es agregando soporte nativo para la migración de esquemas con manage.py migrate y manage.py makemigrations (migrate desaprobado syncdb).