Re: Restauration de dump dans un nouveau schéma

Le mardi 12 février 2013 18:03:40 Dimitri Fontaine a écrit :
> Nabil Servais <nabil(dot)servais(at)gmail(dot)com> writes:
> > Mais pour la partie des tables qui n'ont pas été modifiées, peut on
> > essayer
> > d'insérer le données?
>
> Pour ces tables là, faire une restauration partielle à l'aide des option
> -l et -L de pg_restore, appliquées à une sauvegarde au format "custom",
> faite avec pg_dump -Fc.
>
> >> Il est conseillé de préparer un script « rollout » contenant les
> >> modifications de schéma afin de l'appliquer après restauration des
> >> données.
> >
> > Existe t'il un outil pour faciliter ce genre d'opérations ?
>
> J'aurais pensé utiliser un « DBA » pour cela. Mais sinon je crois qu'il
> existe des outils dont la mission est de faire le travail à l'envers en
> effet (partir des deux schéma et construire le chemin pour passer de
> l'un à l'autre), mais je laisserai la parole à des gens qui les ont
> utilisé.

Pour générer un diff entre deux états d'une base, pyrseas fait ça plutot bien.

http://pyrseas.readthedocs.org/en/latest/index.html

Le principe est simple: l'outil dbtoyaml scanne les catalogues systèmes, et
produit un fichier yaml représentant l'état de la base (tables, fonctions
etc...).

Ensuite, un autre éxécutable (yamltodb) est capable de générer un script de
migration en comparant le fichier yaml à une base.

Attention cependant à ne pas placer une confiance aveugle dans l'outil: les
scripts générés (du moins quand je l'avais utilisé) peuvent ne pas être
adaptés du tout. Je pense notamment à des modifications / renommage de
colonnes.

Pour gérer les changements du schéma ainsi que leur déploiement, je vous
invite à regarder sqitch qui permet de poser un cadre au développement de
scripts de migration.

Voir ici: http://sqitch.org/ et là:
https://metacpan.org/module/sqitchtutorial.

--
Ronan Dunklau