Doctrine migrate: quando ci si accorge di essere in ritardo

A volte può capitare di essere pronti per il deploy di una applicazione quando ci accorgiamo di aver dimenticato di creare gli script per aggiornare il database in produzione.
Con Symfony, Doctrine e un sistema di versioning è possibile rimediare molto facilmente.
Questa è la mia ricetta:

  • Recuperare la versione di
    config/doctrine/schema.yml

    che rappresenta il database in produzione (verosimilmente il file che è adesso in produzione 😉 oppure con il sistema di versioning)

  • Lanciare
    ./symfony doctrine:build --all
  • Copiare l’attuale file
    config/doctrine/schema.yml

    in un posto sicuro

  • Sostituire il file
    config/doctrine/schema.yml

    con la copia “vecchia” recuperata

  • Lanciare
    ./symfony doctrine:generate-migrations-diff

    (se necessario con il parametro env settato)

  • Aprire il file
    *version*.php

    appena creato dalla procedura in

    lib/migration/doctrine

    (se è la prima volta che migri ce n’è uno solo altrimenti apri solo l’ultimo)

  • Inverti il nome dei metodi “up()” e “down()”, cioè sostituisci il nome “up()” con “down()” e viceversa
  • Riporta lo
    schema.yml

    all’ultima versione

  • Ora puoi lanciare il task di migrazione
    ./symfony doctrine:migrate
  • Nel caso di errori di CHARSET o COLLATION nel lanciare il task precedente, verifica che nel file di migrazione che hai modificato precedentemente non siano presenti i parametri ‘charset’ e ‘collate’ come opzioni dei metodi createTable()

Buona migrazione a tutti.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone
Written by kea

1 Comment

  1. gionn

    Non ho capito il senso dell’invertire le funzioni up() e down(), hai provato a buildare le classi con lo schema “vecchio”, aggiornare allo schema “nuovo” e generare migrations-diff?

Leave a Reply

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *