Gestione della migrazione delle viste del database in un ambiente con più sviluppatori

Question

Esistono pratiche consolidate su come la migrazione delle viste del database possa essere gestita con successo in un ambiente multi-sviluppatore/multi-ramo (VCS)?

Abbiamo utilizzato una libreria di migrazione del database per tutte le modifiche dello schema, ma abbiamo incontrato problemi quando diversi sviluppatori in diversi rami di codice hanno modificato la stessa vista, ma il loro punto di origine era lo stesso.

Ogni sviluppatore dispone di una propria copia del database, ma in genere le visualizzazioni richiedono che venga specificata l'intera definizione nella migrazione, ciò significa che quando si eseguono le migrazioni sul database di gestione temporanea o di produzione, qualunque sia la visualizzazione della migrazione run last sovrascrive tutte le modifiche apportate in qualsiasi precedente visualizzazione delle migrazioni.

Esempio:

1. View attualmente assomiglia: SELECT 'x'.
2. Lo sviluppatore 1 avvia il ramo A e aggiunge una nuova colonna. La loro migrazione "su" è simile a: SELECT 'x', 'y'.
3. Lo sviluppatore 2 avvia il ramo B e aggiunge una nuova colonna. La loro migrazione "su" assomiglia a: SELECT 'x', 'z'.
4. Lo sviluppatore 2 termina la filiale e esegue le migrazioni. La vista ora sembra SELECT 'x', 'z'.
5. Lo sviluppatore 1 termina il suo ramo e esegue le migrazioni. La vista ora sembra SELECT 'x', 'y' e le modifiche dello sviluppatore 2 sono andate perse.

Answer 1

Se lavorano in rami di codice diversi, dovrebbero utilizzare database diversi; e quando i rami sono uniti, le differenze dovrebbero essere risolte.

Detto questo, sono dell'opinione che uno schema debba essere trattato come se fosse un "progetto". Si menzionano più sviluppatori che modificano una VISTA condivisa, quando non è meno significativo un cambiamento rispetto a qualcuno che modifica la firma di una funzione comunemente usata in una DLL condivisa.

La mia risposta è (se non è troppo tardi nello sviluppo) avere un codice client standard di connettersi con un utente MySQL che non ha il permesso di modificare il database più del necessario; e avere una "migrazione" applicazione/script/tutto ciò che viene eseguito con una connessione sotto un account utente con le autorizzazioni necessarie per modificare tabelle, viste, procedure, ecc ...

Answer 2

Per le viste, o qualsiasi oggetto di database che può essere ridefinito in qualsiasi momento (es. funzioni), la best practice che ho trovato è quella di memorizzare la definizione corrente della funzione nel proprio file, ad esempio, db/views/your_stuff.view.sql; poi, ogni volta che uno sviluppatore vuole cambiare quella vista, cambia quel file, quindi aggiunge una migrazione boilerplate che semplicemente ridefinisce la vista dall'ultima versione (non so se sei in Rails o no, ma l'idea qui dovrebbe essere abbastanza chiaro):

class UpdateYourStuffView < ActiveRecord::Migration 
    def up 
    execute File.read("#{Rails.root}/db/views/your_stuff.view.sql") 
    end 

    def down 
    # You could expand this to actually track older versions, 
    # but that's generally not worth it. 
    raise ActiveRecord::IrreversibleMigration 
    end 
end 

Nota che il file di vista reale dovrebbe assomigliare:

CREATE OR REPLACE VIEW your_stuff AS (SELECT 'x' FROM foos); 

questo risolve il problema, perché il flusso di lavoro è ora:

1. View attualmente si presenta come : SELECT 'x' FROM foos.
2. Lo sviluppatore 1 avvia il ramo A e aggiunge una nuova colonna. Modificano db/views/your_stuff.view.sql per riflettere questa modifica; la loro migrazione esegue semplicemente la nuova vista.
3. Lo sviluppatore 2 avvia il ramo B e aggiunge una nuova colonna. Modificano lo stesso file e aggiungono una nuova migrazione esattamente come sopra.
4. Lo sviluppatore 2 termina la filiale e esegue le migrazioni. La vista ora appare come SELECT 'x', 'z'.
5. Lo sviluppatore 1 termina il suo ramo. Tuttavia, per unire in master, , è necessario risolvere il conflitto nel file di visualizzazione. Una volta che lo fa, ed esegue le migrazioni, la vista ora include tutte e tre le colonne.