Schema Patches Practices

Question

Abbiamo uno schema in Postgres, e vogliamo istituire un buon metodo per applicare le patch di schema.

Al momento, abbiamo una serie di file DDL che creano lo schema, tabelle, sequenze, funzioni, ecc Abbiamo anche uno script di popolazione per ambienti di test. Questi file sono tutti utilizzati per ricreare i nostri ambienti di database, per lo sviluppo, il test, ecc.

Abbiamo anche un certo numero di file 'patch' che corrispondono alle versioni del nostro sistema. vale a dire. patch / 1.0.0.sql, patches / 1.0.1.sql, ecc Questi file vengono utilizzati per aggiornare i nostri database di gestione temporanea e di produzione.

Questo processo funziona per noi finora, ma c'è stato un certo dibattito in-house come patch meglio lo schema.

Sono curioso ciò che gli altri là fuori hanno, come un processo, di patch messa in scena e di schemi di produzione e come gestire le versioni del database.

Grazie!

Answer 1

Al lavoro, per SQL Server, scriviamo script modifica dello schema che prima rollback la modifica da effettuare (idempotently, quindi la sezione rollback funziona bene anche se la modifica dello schema non è ancora applicata), e poi una sezione per applicare la modifica. In TSQL è facile sbirciare nel catalogo di sistema o di altri tavoli per vedere se esistono già e non fare nulla, se non tabelle / colonne / indici / righe.

In PostgreSQL, sei un po 'più limitata di quello che i comandi si può semplicemente inviare al server--, ma d'altra parte, DDL è transazionale, quindi un cambiamento a metà applicata schema non dovrebbe accadere. Ho adattato il sistema di cui sono abituato al lavoro per utilizzare su miei piccoli progetti abbastanza bene, per esempio (eccessivo, ma anche qui ho un dev / test db e un db "reale"?):

\echo Rolling back schema change #35

BEGIN;

DELETE FROM schema_version WHERE schema_id = 35;

DROP TABLE IF EXISTS location_coordinates;
DROP FUNCTION IF EXISTS location_coordinates_populate();

END;

\echo Applying schema change #35

BEGIN;

INSERT INTO schema_version(schema_id, description) VALUES(35, 'Add location_coordinates table');

CREATE TABLE location_coordinates(
 location_id INT PRIMARY KEY REFERENCES location(location_id),
 latitude FLOAT NOT NULL,
 longitude FLOAT NOT NULL,
 earth_coordinates earth NOT NULL,
 box_10miles cube NOT NULL
);

GRANT SELECT, INSERT, UPDATE, DELETE ON location_coordinates TO ui;

CREATE FUNCTION location_coordinates_populate() RETURNS TRIGGER LANGUAGE 'plpgsql' AS $$
BEGIN
  new.earth_coordinates := ll_to_earth(new.latitude, new.longitude);
  new.box_10miles := earth_box(new.earth_coordinates, 10 * 1609.344);
  RETURN new;
END
$$;

CREATE TRIGGER location_coordinates_populate BEFORE INSERT OR UPDATE ON location_coordinates
 FOR EACH ROW EXECUTE PROCEDURE location_coordinates_populate();

INSERT INTO location_coordinates(location_id, latitude, longitude)
 SELECT location_id, latitude, longitude FROM location WHERE latitude IS NOT NULL AND longitude IS NOT NULL;

CREATE INDEX location_coordinates_10miles ON location_coordinates USING gist (box_10miles);

END;

\echo Done

Questo script può essere eseguito sul database appena con "psql -f schema-modifiche / 35.sql". Con solo tagliando fuori fino al messaggio "l'applicazione di ...", posso ottenere i comandi a rotolare indietro. E come si può vedere, il cambiamento mantiene una tabella dei metadati "SCHEMA_VERSION" in modo da poter vedere quale vengono applicate le modifiche. L'intera variazione è fatto come una transazione, la migrazione dei dati e di tutti. Qui ho usato la capacità di "IF EXISTS" della caduta di comandi per rendere la sezione di rollback felice anche quando il cambiamento è non applicato. Istr una cosa che abbiamo fatto al lavoro per Oracle è stato modifiche allo schema di scrittura come PL / SQL-- si potrebbe forse avere alcune funzioni in plpgsql per aiutare con le modifiche?

Si noti che nel cambiamento di cui sopra, dove sto migrando la "latitudine" e le colonne "di longitudine" (che erano nullable) di "location" per una relazione separata "location_coordinates" (e aggiungendo la roba earthdistance), non ho fatto cadere le vecchie colonne. Una cosa che dobbiamo stare attenti è quello di apportare modifiche allo schema retro-compatibile, se possibile. Così posso applicare questa modifica dello schema prima aggiornare l'applicazione per utilizzare le nuove tabelle. Avrei un secondo cambiamento di abbandonare le vecchie colonne di applicare dopo aggiornare l'applicazione. Al lavoro, questi verrebbero fatto in due cicli di rilascio diverse, quindi durante liberatoria X abbiamo ancora opzionale di rotolare indietro all'applicazione di rilasciare X-1 senza dover ripristinare tutte le modifiche dello schema prima; oltre ad essere in grado di implementare le modifiche dello schema in una finestra separata prima che le applicazioni. (Tecnicamente avrei dovuto scrivere un trigger in modo aggiornamenti alla vecchia tabella vengono sincronizzati con la nuova tabella, ma non ho perché è troppo simile lavoro:))

Abbiamo anche cose come un'applicazione che i ragni tutti i nostri database per vedere cosa c'è nella tabella schema_version, e tiene traccia delle modifiche, così la gente può anche vedere quali modifiche sono state fatte senza dover collegare, e farsi un'idea della storia di ogni cambiamento (si traccia "rollback in dev", "applicato in dev", ecc). Al lavoro nostro tavolo SCHEMA_VERSION include anche informazioni paternità ecc Un modo magico di applicare le informazioni sulla versione dal controllo di versione sarebbe raffredda- un problema che abbiamo è che se un SC viene applicato in QA, per esempio, poi cambiato in Perforce, forse no comunicazioni -one. Quindi un modo per tenere traccia che modifica dello schema di revisione 35 # 4 è stato applicato sarebbe buono.

Una cosa da notare-modifiche dello schema per noi sono numerati indipendentemente versioni dell'applicazione. Ovviamente sono legati --- questa è un'altra cosa che l'applicazione spidering permette alle persone di entrare --- ma cerchiamo di avere un sacco di piccoli cambiamenti, piuttosto che un gigante "Ecco tutto quello per il rilascio X" patch. Le modifiche dello schema sono utilizzati anche per cose come l'aggiunta di nuovi indici, quindi potrebbero non essere app-driven a tutti. In generale, le modifiche dello schema sono "posseduti" da parte degli sviluppatori, non DBAs- anche se nel "creare indice" esempio di cui sopra, il DBA è fondamentalmente agisce in un ruolo di sviluppatore e possedere la modifica dello schema. Sì, noi insistiamo su un elevato livello di SQL-abilità da developers- anche se altri gruppi della società funzionano un po 'diversamente e danno più lavoro per il team DB.