Hello,

je me demandais aussi quel était le chemin de migration le plus propre pour

• ne pas casser les sites existants
• permettre au nouveaux de se construire sur les nouvelles régions
• permettre à ceux qui veulent de migrer, ce qui implique effectivement une 
migration en base et du changement de code possiblement.

La proposition de touti à l’avantage de ne pas casser, mais on va se retrouver 
avec des id_nouvelles_regions qu’on va trainer des années, et à un moment ou à 
un autre il faudra renommer en « regions » car les « nouvelles régions » dans 
10 ans ça sera un peu balot. Et alors on aura toujours/encore le soucis de 
migration, changement de code etc.

La proposition de maieul est pas mal, MAIS on risque d’avoir des upgrades 
involontaires parce que SVP dira « hé y a une version 2 du plugin geographies » 
et les gens cliqueront sur mise à jour sans savoir que leur base de données 
devient tout à coup incohérente.

Donc je pense qu’il faut aller un tout petit peu plus loin en mettant un 
nouveau prefixe sur la branche de la v2 pour éviter la proposition de migration 
automatique (et une balise <procure> sur le nouveau plugin pour qu’il dire 
qu’il procure bien les fonctions de geographies).
Et comme maieul le propose, une fonction de migration réutilisable pour 
permettre à ceux qui doivent migrer des tables en relation de le faire 
facilement.

--
Cédric
Le 12 oct. 2019 à 12:12 +0200, toutati <tout...@free.fr>, a écrit :
> Hello,
>
> et pourquoi ne pas rajouter une table "nouvelles_regions" qui regroupe
> les départements idoines et qu'on peut appeler seulement si on le souhaite ?
>
> ++
>
> Le 11/10/2019 à 12:37, Maïeul Rouquette a écrit :
> > Holla,
> >
> > le plugin géographie fonctionne toujours avec les anciennes régions.
> >
> > Est-ce qu'il ne faudrait pas passer aux nouvelles régions ?
> > Pour des installations neuves, cela ne devrait pas poser de problème. En
> > revanche pour des installations plus ancienne, se pose la question de la
> > migration :
> > - pour les tables du plugin proprement dit, pas de souci
> > - en revanche pour les tables qui utilisent les identifiants des régions
> > comment faire ?. Je pense notamment aux champs extra éventuelle
> > (hypothèse relativement peu problable dans la mesure où il n'y a pour le
> > moment pas de possibilité d'ajouter un champ extra de région via
> > l'interface graphique). Ma proposition : le plugin fournirait une
> > function de migration
> > geo_migrer_region_2015($table, $colonne) qui s'occuperait
> > automatiquement de migrer si on l'appelle.
> >
> > Dans une telle hypothèse, on poserait un sabot sur une branche 1, et les
> > nouvelles régions seraient dans la branche 2.
> >
> > Avis bienvenus !
> >
> > Maïeul
> >
> >
> >
> > ----
> > spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à