Flujo de trabajo de Django al modificar modelos con frecuencia?

Question

ya que generalmente no hago el diseño inicial de mis modelos en proyectos de Django, termino modificando mucho los modelos y eliminando así mi base de datos de prueba todo el tiempo (porque "syncdb" nunca alterará las tablas automáticamente para usted) A continuación se encuentra mi flujo de trabajo y me gustaría saber sobre el tuyo. Cualquier idea bienvenida ...

1. Modificar el modelo.
2. Elimina la base de datos de prueba. (siempre una base de datos sqlite simple para mí.)
3. Ejecute "syncdb".
4. Genera algunos datos de prueba a través del código.
5. Goto 1.

Una cuestión secundaria Con respecto a esta .. En caso de que su flujo de trabajo es como la de arriba, ¿cómo se ejecuta el paso 4.? ¿Generas los datos de prueba manualmente o hay un punto de enlace apropiado en las aplicaciones de Django donde puedes inyectar el código de generación de datos de prueba al inicio del servidor? \

TIA.

Answer 1

Pasos 2 & 3 se puede hacer en un solo paso:

manage.py reset appname 

Paso 4 se maneja más fácilmente, desde mi entendimiento, mediante el uso de fixtures

Answer 2

Este es un trabajo para los accesorios de Django. Son convenientes porque son independientes de la base de datos y el arnés de prueba (y manage.py) tienen soporte integrado para ellos.

Para utilizarlos:

1. configurar sus datos de tu aplicación (llamada que "foo") usando la herramienta de administración
2. Crear un directorio de fixtures en el directorio de "foo" aplicación
3. Tipo: python manage.py dumpdata --indent=4 foo > foo/fixtures/foo.json

Ahora, después de la etapa de syncdb, usted solo tiene que:

python manage.py loaddata foo.json 

Y sus datos serán recreados.

Si los quieres en un caso de prueba:

class FooTests(TestCase): 
    fixtures = ['foo.json'] 

Tenga en cuenta que tendrá que volver a crear o actualizar sus accesorios de forma manual si el esquema cambia drásticamente.

Puede leer más acerca de los accesorios en los documentos de Django para Fixture Loading

Answer 3

Esto es lo que hacemos.

1. Las aplicaciones se nombran con un número de versión de esquema. appa_2, appb_1, etc.

2. Los cambios menores no cambian el número.

3. Los cambios importantes incrementan el número. Syncdb funciona. Y se puede escribir un script de "migración de datos".

   def migrate_appa_2_to_3(): 
       for a in appa_2.SomeThing.objects.all(): 
        appa_3.AnotherThing.create(a.this, a.that) 
        appa_3.NewThing.create(a.another, a.yetAnother) 
       for b in ... 
   

El punto es que la gota y recrear no siempre es apropiada. A veces es útil mover datos del modelo anterior al nuevo modelo sin reconstruir desde cero.

Answer 4

Para agregar a la respuesta de Matthew, a menudo también uso SQL personalizado para proporcionar datos iniciales como se documenta here.

Django solo busca archivos en <app>/sql/<modelname>.sql y los ejecuta después de crear tablas durante syncdb o sqlreset. Uso SQL personalizado cuando necesito hacer algo como llenar mis tablas Django desde otras tablas de bases de datos que no sean de Django.

Answer 5

Personalmente mi db de desarrollo es bastante grande para un proyecto en el que estoy trabajando ahora, así que uso dmigrations para crear scripts de migración db para modificar el db (en lugar de borrar el db cada vez como lo hice al principio)

Editar: En realidad, estoy usando ahora :-) Sur

Answer 6

del Sur es el más fresco.

Aunque el buen reinicio funciona mejor cuando los datos no importan.

http://south.aeracode.org/