python - query - sqlalchemy select example

¿Cómo administrar eficientemente los cambios de esquema frecuentes usando sqlalchemy? (4)

Estoy programando una aplicación web usando sqlalchemy. Todo fue sencillo durante la primera fase de desarrollo cuando el sitio no estaba en producción. Podría cambiar fácilmente el esquema de la base de datos simplemente borrando la vieja base de datos sqlite y creando una nueva desde cero.

Ahora el sitio está en producción y necesito preservar los datos, pero aún quiero mantener mi velocidad de desarrollo original convirtiendo fácilmente la base de datos al nuevo esquema.

Entonces digamos que tengo model.py en la revisión 50 y model.py una revisión 75, que describe el esquema de la base de datos. Entre esos dos esquemas, la mayoría de los cambios son triviales, por ejemplo, una nueva columna se declara con un valor predeterminado y solo deseo agregar este valor predeterminado a los registros anteriores.

Eventualmente, algunos cambios pueden no ser triviales y requieren un pre-cálculo.

¿Cómo maneja (o manejaría) las aplicaciones web que cambian rápidamente con, por ejemplo, una o dos versiones nuevas del código de producción por día?

Por cierto, el sitio está escrito en Pilones si esto hace alguna diferencia.

La mejor manera de lidiar con su problema es reflejar su esquema en lugar de hacerlo de manera declarativa. Escribí un artículo sobre el enfoque reflexivo aquí: http://petrushev.wordpress.com/2010/06/16/reflective-approach-on-sqlalchemy-usage/ pero también hay otros recursos sobre esto. De esta manera, cada vez que realice cambios en su esquema, todo lo que necesita hacer es reiniciar la aplicación y la reflexión obtendrá los nuevos metadatos para los cambios en las tablas. Esto es bastante rápido y sqlalchemy lo hace solo una vez por proceso. Por supuesto, tendrás que gestionar los cambios de relaciones que hagas tú mismo.

Que hacemos

Utilice la identificación "versión principal". "Versión menor" de sus aplicaciones. La versión principal es el número de versión del esquema. El número principal no es un tipo aleatorio de "suficiente funcionalidad nueva". Es una declaración formal de compatibilidad con el esquema de la base de datos.
Las versiones 2.3 y 2.4 usan esquema versión 2.
La versión 3.1 usa el esquema de la versión 3.
Haga que la versión del esquema sea muy, muy visible. Para SQLite, esto significa mantener el número de versión del esquema en el nombre del archivo de la base de datos. Para MySQL, use el nombre de la base de datos.
Escribir guiones de migración. 2to3.py, 3to4.py. Estas secuencias de comandos funcionan en dos fases. (1) Consulta los datos antiguos en la nueva estructura creando archivos CSV o JSON simples. (2) Cargue la nueva estructura desde los archivos simples CSV o JSON sin procesamiento adicional. Estos archivos de extracción, debido a que están en la estructura adecuada, son rápidos de cargar y pueden usarse fácilmente como accesorios de prueba de la unidad. Además, nunca tiene dos bases de datos abiertas al mismo tiempo. Esto hace que los scripts sean un poco más simples. Finalmente, los archivos de carga se pueden usar para mover los datos a otro servidor de base de datos.

Es muy, muy difícil "automatizar" la migración de esquemas. Es fácil (y común) tener una cirugía de base de datos tan profunda que un script automatizado no puede mapear fácilmente los datos del esquema anterior al nuevo esquema.

Use sqlalchemy-migrate .

Está diseñado para admitir un enfoque ágil del diseño de la base de datos y facilitar la sincronización de las bases de datos de desarrollo y producción, ya que se requieren cambios en el esquema. Hace versiones de esquema fáciles.

Piense en ello como un control de versión para su esquema de base de datos. Usted le asigna cada cambio de esquema y podrá avanzar o retroceder en las versiones de esquema. De esta forma, puede actualizar un cliente y sabrá exactamente qué conjunto de cambios aplicar en la base de datos de ese cliente.

Hace lo que S.Lott propone en su respuesta, automáticamente para usted. Hace que lo difícil sea fácil.

Alembic es una nueva herramienta de migración de bases de datos, escrita por el autor de SQLAlchemy. Me pareció mucho más fácil de usar que sqlalchemy-migrate. También funciona a la perfección con Flask-SQLAlchemy.

Genere automáticamente la secuencia de comandos de migración de esquema desde sus modelos de SQLAlchemy:

alembic revision --autogenerate -m "description of changes"

A continuación, aplique los nuevos cambios de esquema a su base de datos:

alembic upgrade head

Más información aquí: http://readthedocs.org/docs/alembic/