¿Cómo se puede controlar efectivamente la versión de los parameters de la aplicación almacenados en una database?

Tenemos una aplicación altamente personalizable que se adapta a las necesidades de varios clientes que usan parameters almacenados en una database PostgreSQL.

Por ejemplo, aquí hay una estructura de ejemplo de la tabla de parameters.

CREATE TABLE parameters ( client_id VARCHAR(32) NOT NULL, environment_key VARCHAR(32) NOT NULL, param_name VARCHAR(255) NOT NULL, param_value TEXT ); 

Las inputs de ejemplo en esta tabla pueden verse así:

 CLIENT_A PRODUCTION REMOTE_SERVER "12.34.56.78" CLIENT_B PRODUCTION REMOTE_SERVER "78.56.34.12" CLIENT_B STAGING REMOTE_SERVER "127.0.0.1" 

Cada desarrollador tiene una copy de trabajo de subversión en su computadora local Y una copy de la database. No es un problema cuando un desarrollador cambia algún código, ya que el control de la versión de SVN se encarga de los detalles (por ejemplo, fusionar files durante una actualización, asegurarse de que la máquina de creación / puesta en escena tenga la última copy, etc.). Sin embargo, nos encontramos con problemas cuando alguien modifica los parameters en la database, porque los loggings NO están controlados por la versión . Esto provoca, por ejemplo, que los parameters actualizados de un desarrollador sobrescriban los de otro, los parameters que faltan en la máquina de creación / preparación, etc.

PREGUNTA: ¿Cuál es la forma más efectiva de resolver el problema anterior?

Puedo pensar en varias opciones, es posible que tenga otras alternativas.

  1. No almacene parameters en la database. Guárdelos en algún tipo de file de versión controlada (por ejemplo, XML, JSON, TXT, etc.).
  2. Cree un script o C-plugin para PostgreSQL para volcar el contenido de cada logging en la copy de trabajo.

Probablemente sea más simple poner la tabla bajo control de versión y editar sus files MAKE un poco para asegurarse de que la database esté actualizada.

Puede volcar una sola tabla en el disco con pg_dump . Las opciones de command-line le permiten volcar solo el esquema, solo los datos, o ambos. Esta línea de command vuelca los datos de mi tabla de elementos químicos a stdout.

 $ pg_dump -h localhost -U postgres -t chemical_elements --data-only sandbox 

Los desarrolladores probablemente actualizarán la database en sí. Puede escribir la salida de pg_dump en un file temporal y usar el estado de salida de diff o cmp para determinar si la versión controlada y los datos actuales son diferentes.

Otro enfoque (de alguna manera alternativo al modo de Mike) es agregar versiones a todos los cambios en la database y se puede hacer de manera bastante fácil y transparente con Liquibase sobre el código-SCM y PostgreSQL

Para los usuarios finales (desarrolladores) significa que aparece un file adicional (logging de cambios de Liquibase) en las confirmaciones de SVN normales y actualiza la database local solo a través de la actualización de Liquibase.

Mantenga la versión definitiva de sus datos de parameters en el control de versiones:

 begin; delete from parameters; insert into parameters values ('CLIENT_A', 'PRODUCTION', 'REMOTE_SERVER', '12.34.56.78'); insert into parameters values ('CLIENT_B', 'PRODUCTION', 'REMOTE_SERVER', '78.56.34.12'); insert into parameters values ('CLIENT_B', 'STAGING', 'REMOTE_SERVER', '127.0.0.1'); commit; 

Use ganchos post-commit en subversion para aplicar el script cada vez que se actualice.

 #!/bin/sh # Post-commit hook for applying parameter changes to db REPOS="$1" REV="$2" DB=mydb PARAM_SCRIPT="$REPOS/sql/parameters.sql" psql "$DB" < "$PARAM_SCRIPT"