Puis-je intégrer cela dans le plugin geographie en trunk ?
Comment procède-t'on au niveau des paquets pour éviter de tout casser chez les gens ?
Je propose de:
- passer le trunk en v1
- brancher le zip actuel sur cette v1
- poser la mise a jour regions dans le nouveau trunk.
- faire un nouveau zip pour cette version et passer en 1.1.0
A terme, il faudrait réfléchir car à l'installation neuve, géographie requiert un nombre très important de requêtes et sur des serveurs un peu léger, on obtient facilement un timeout (ou un script qui tourne en boucle).
Sur le principe oui, je dirais de copier dans une branche l'actuel, et de faire la modif en trunk.
Mais plutôt un changement de X non ?
Parce que là, on change le contenu d'une table entière, et ce sont des tables de contenus fixes. Or, tous ceux qui utilisaient les régions avant peu importe le besoin, bah là tout va être pété : chaque id_region ne va plus correspondre à la même chose, et il y en aura moins, etc.
Donc dis comme ça, moi ça me parait un changement majeure puisque cassage de compatibilité, donc 2.0.0.
Par ailleurs, ya un truc qui me parait bancal, c'est que là ceux qui vont installer le plugin, et ceux qui vont mettre à jour ne vont pas avoir les mêmes id_region pour chacune. Or ce plugin est un peu spécial puisque tout y est "fixe". Donc s'il y a des configs etc basées sur les identifiants des territoires, ça me parait péter des choses. Théoriquement avec ce plugin, on est censé toujours avoir les mêmes infos partout, y compris les ids SQL.
Voilà ce qui me vient sur ce plugin pour le moment.
Cette histoire de changement de région n'a pas fini de mettre la pagaille un peu partout... D'autant que les anciennes régions sont toujours utilisées par-ci par-là, il n'y a qu'à regarder des cartes météo pour s'en rendre compte.
Ne serait-il pas plus indiqué de créer un niveau supplémentaire "grande région", dont les régions précédentes ne seraient qu'un découpage intermédiaire? Ça ne casserait rien et on garderait les compatibilités.
CM
Le 25/11/2016 à 23:33, RastaPopoulos a écrit :
Sur le principe oui, je dirais de copier dans une branche l'actuel, et
de faire la modif en trunk.
Mais plutôt un changement de X non ?
Parce que là, on change le contenu d'une table entière, et ce sont des
tables de contenus fixes. Or, tous ceux qui utilisaient les régions
avant peu importe le besoin, bah là tout va être pété : chaque id_region
ne va plus correspondre à la même chose, et il y en aura moins, etc.
Donc dis comme ça, moi ça me parait un changement majeure puisque
cassage de compatibilité, donc 2.0.0.
Par ailleurs, ya un truc qui me parait bancal, c'est que là ceux qui
vont installer le plugin, et ceux qui vont mettre à jour ne vont pas
avoir les mêmes id_region pour chacune. Or ce plugin est un peu spécial
puisque tout y est "fixe". Donc s'il y a des configs etc basées sur les
identifiants des territoires, ça me parait péter des choses.
Théoriquement avec ce plugin, on est censé toujours avoir les mêmes
infos partout, y compris les ids SQL.
Voilà ce qui me vient sur ce plugin pour le moment.
Mais coté insee et cie, je ne vois pas encore la prise en charge des
nouvelles régions.
L'idée d'ajouter les régions manquantes et de passer en obsolétes les
anciennes (par exemple avec l'idée des grandes régions) pourrait
limiter la casse.
Mais coté insee et cie, je ne vois pas encore la prise en charge des
nouvelles régions.
L'idée d'ajouter les régions manquantes et de passer en obsolétes les
anciennes (par exemple avec l'idée des grandes régions) pourrait
limiter la casse.
Ne pas oublier les dom qui ont aussi bougé.
ce n'est pas forcement trivial comme on a aussi des liaisons sur la base region
- id_region sur la table spip_geo_departements
- id_region sur la table spip_geo_regions_liens
si on part sur cette stratégie, techniquement vous voyez cela comment ?
option 1
-----------------
- ajout d'une nouvelle colonne "nom_reforme" à la table spip_geo_regions
les regions d'une même grande région aurait le même nom
- au niveau boucle, il faudrait jouer avec fusion pour obtenir la liste des regions uniques (mais on n'aurait pas à toucher aux liaisons)
option 2
-----------------
- ajouter une colonne "obsolete" a spip_geo_regions
- passer les anciennes regions en obsoletes
- ajouter les nouvelles grandes régions
et comment on gérerait les liaisons ?
une autre stratégie ?
cela sent quand même le bricolage mais au moins cela ne casse rien à la mise à jour du plugin
cela sent quand même le bricolage mais au moins cela ne casse rien à la
mise à jour du plugin
Mais quel est l'intérêt ?
Ce sont les vieilles régions, point. On n'y peut rien maintenant. Vieilles régions = vieux plugin.
Ceux qui continuent d'avoir besoin des vieilles régions continuent d'utiliser l'ancienne branche du plugin, qui appartient au passé, avec seulement des corrections de bugs dedans. Ya pas de mal à ça.
Et dans le trunk que les nouvelles régions (au propre, avec les bons id_region partout les mêmes, nouvelle install ou mise à jour).
Ceux qui mettent à jour sur la nouvelle branche doivent le faire en connaissance de cause : d'où le changement de X qui indique bien de faire attention.
C'est plus simple, plus pérenne, plus propre, d'après moi.
Les personnes qui ont besoin des vieilles régions reste sur le vieux plugin
les autres passent au nouveau plugin qui met à jour vers les nouvelles régions
au niveau code, tout fonctionne
sauf la gestion des spip_geo_regions_liens que je n’arrive pas à traiter simplement on risque d’avoir des doublons ce qui est interdit sur cette table de liaisons il faudrait faire un requete du type pour effacer les futurs doublons
Je le redis mais là ce code va faire que celleux qui vont installer à neuf vont avoir Auvergne-Rhône-Alpes id_region=1, alors que celleux qui vont mettre à jour auront id_region=22 ou un truc comme ça.
Vu comment a toujours fonctionné le plugin avec des contenus uniquement "fixes" et pareils partout, ça ne me parait pas du tout correct.
À priori il faudrait d'abord la vider, remettre la table à zéro et ensuite insérer les nouvelles :
Je le redis mais là ce code va faire que celleux qui vont installer à neuf vont avoir Auvergne-Rhône-Alpes id_region=1, alors que celleux qui vont mettre à jour auront id_region=22 ou un truc comme ça.
Vu comment a toujours fonctionné le plugin avec des contenus uniquement "fixes" et pareils partout, ça ne me parait pas du tout correct.
je ne crois pas car ce code serait inséré dans les étapes de mise à jour via geographie_administration.php et donc on aurait toujours le même id.
si on vide, il faudrait aussi aussi vider les départements et les réimporter alors.
et il y a aussi le problème des liaisons qu'on perd (dans le cadre d'un site qui fait évoluer ses données)
Je le redis mais là ce code va faire que celleux qui vont installer à
neuf vont avoir Auvergne-Rhône-Alpes id_region=1, alors que celleux
qui vont mettre à jour auront id_region=22 ou un truc comme ça.
Vu comment a toujours fonctionné le plugin avec des contenus
uniquement "fixes" et pareils partout, ça ne me parait pas du tout
correct.
je ne crois pas car ce code serait inséré dans les étapes de mise à jour
via geographie_administration.php et donc on aurait toujours le même id.
Si si Rastapopoulos a raison : sur une installation vierge on ne passera pas par ce code mais on creera la table et on la peuplera directement avec les bonnes régions, qui auront donc des id commençant à 1
Et lors d'une mise à jour on aura par contre les nouvelles régions avec un id qui commence à N+1 (N etant le nombre de vieilles régions), et des trous dans les régions de 1 à N.
si on vide, il faudrait aussi aussi vider les départements et les
réimporter alors.
et il y a aussi le problème des liaisons qu'on perd (dans le cadre d'un
site qui fait évoluer ses données)
En effet, si on vide ça sera pas mieux et on perd les liaisons existantes.
Il faut donc faire mieux que ça.
Pour chaque nouvelle région :
- Renommer la première des vieilles régions qui la compose au lieu d'insérer un nouvel ID
- ensuite il faut supprimer les autres vieilles régions et remappant les liens sur le nouvel ID au passage. Pour ça il faut faire un sql_select+sql_fecth+sql_updateq pour chaque ancien lien qu'on veut renommer. Puis finir par un sql_delete sur les liens qui restent et qui correspondent aux doublons dont la requete sql updateq aura échoué
Une fois cela fait on a les nouvelles régions avec les bons liens, mais il reste des trous dans les ID correspondant aux anciennes régions supprimées.
2 solutions :
- on modifie l'installation pour que sur une installation neuve on ait les mêmes IDs avec des trous, en assumant en quelque sorte cette curiosité historique
- on fait une seconde passe de renumérotation des IDs. Il faut parcourir les régions par ID croissant, compter les trous, et à chaque ID après un ou plusieurs trous faire un update id=id-nbtrous y compris sur les liens
je ne sais pas si on va s'en sortir ....
C'est pas un update simple, et il est impératif de tester le code et de s'assurer que les 2 scénarios Installation neuve et mise à jour depuis les anciennes régions aboutissent à la même table de régions, avec les mêmes IDs
Cette histoire de changement de région n'a pas fini de mettre la
pagaille un peu partout... D'autant que les anciennes régions sont
toujours utilisées par-ci par-là, il n'y a qu'à regarder des cartes
météo pour s'en rendre compte.
Ne serait-il pas plus indiqué de créer un niveau supplémentaire "grande
région", dont les régions précédentes ne seraient qu'un découpage
intermédiaire? Ça ne casserait rien et on garderait les compatibilités.
Oui, c'est vrai que je suis aussi partagé. Il me semble qu'il faudrait conserver un moyen d'accès aux anciennes régions après cette mise à jour.
Alors du coup, est-ce que renommer la table "régions" en "anciennes_regions" pourrait être fait par exemple (ou une autre solution qui conserve cette information ?)
On aurait :
- spip_geo_regions (les nouvelles)
- spip_geo_anciennes_regions (ou tout autre nom daté peut être, tel que spip_geo_regions_1982 )
- un renommage dans les tables de liaisons du type 'region' vers 'anciennes_region' / ajout d'un champ id_anciennes_region sur les départements
- une copie des liaisons anciennes vers le type 'region' et id adapté.
Ce que j'ai l'impression, c'est que même si juridiquement / administrativement les nouvelles régions sont actées, présentes, il n'en reste pas moins que les anciennes sont toujours utilisées. Et j'imagine bien qu'on puisse vouloir les 2 usages sur un même site (ie: des filtres géographiques par nouvelles régions / anciennes régions).
C'est vrai que je reste dans la supposition, mais bizarrement ça me gêne de "perdre" cette info.
Ce n'est juste qu'un avis pour la discussion… ma foi peut m'importe ce qui sera fait, c'est vrai que le plus important déjà est d'avoir accès aux nouvelles régions !
Le 27/11/2016 à 11:29, Matthieu Marcillaud a écrit :
Cette histoire de changement de région n'a pas fini de mettre la
pagaille un peu partout... D'autant que les anciennes régions sont
toujours utilisées par-ci par-là, il n'y a qu'à regarder des cartes
météo pour s'en rendre compte.
Ne serait-il pas plus indiqué de créer un niveau supplémentaire "grande
région", dont les régions précédentes ne seraient qu'un découpage
intermédiaire? Ça ne casserait rien et on garderait les compatibilités.
Et dire que le but originel est une simplification ... bienvenue à un nouvel étage administratif, la "grande région" ...
Perso je ne comprends pas pourquoi on aurait besoin d'accèder aux anciennes régions. La modification n'est pas finie mais elle est clairement en cours, j'ai des demandes constantes pour passer aux nouvelles régions, pour changer les logos, etc etc. Météofrance va rapidement se faire réprimander s'ils ne changent pas, c'est une question de temps.
Oui moi aussi je suis d'accord avec ça, on a pas à gérer les 2 à la fois : soit on a du vieux code qui tourne avec les vieilles régions et on reste comme ça, soit on passe sur les nouvelles ou on démarre un projet et on utilise les nouvelles, mais dans ce cas on a pas à faire référence ou donner accès aux anciens découpages de région.
Ou si certains pourraient avoir ce besoin, c'est du cas particulier qu'ils traiteront dans leur coin, car ça n'a rien de pérenne ni d'interêt commun.
--
Cédric
Zedd a écrit :
Bonjour,
Le 27/11/2016 à 11:29, Matthieu Marcillaud a écrit :
Cette histoire de changement de région n'a pas fini de mettre la
pagaille un peu partout... D'autant que les anciennes régions sont
toujours utilisées par-ci par-là, il n'y a qu'à regarder des cartes
météo pour s'en rendre compte.
Ne serait-il pas plus indiqué de créer un niveau supplémentaire "grande
région", dont les régions précédentes ne seraient qu'un découpage
intermédiaire? Ça ne casserait rien et on garderait les compatibilités.
Et dire que le but originel est une simplification ... bienvenue à un
nouvel étage administratif, la "grande région" ...
Perso je ne comprends pas pourquoi on aurait besoin d'accèder aux
anciennes régions. La modification n'est pas finie mais elle est
clairement en cours, j'ai des demandes constantes pour passer aux
nouvelles régions, pour changer les logos, etc etc. Météofrance va
rapidement se faire réprimander s'ils ne changent pas, c'est une
question de temps.
[...] Météofrance va rapidement se faire réprimander s'ils ne changent pas,
c'est une question de temps.
Non, de géographie. Déjà rien que pour la Bourgogne, le climat est différent entre le nord (plateau de Langres), l'ouest (Yonne, Nièvre), le centre (Morvan) et le sud-est (val de Saône). Et en Franche-Comté c'est encore autre chose puisque c'est le massif du Jura. Même genre de remarque pour Champagne/Lorraine/Alsace ou l'Aquitaine du Pays basque au Limousin...
Il n'y a pas que la météo. Par exemple le Bon Coin aussi a gardé le découpage en anciennes régions...
Ces "grandes régions" ne sont qu'une incongruité administrative de plus. On complique la vie de bien des gens (la preuve) sous prétexte d'économies qui restent à prouver. Enfin, si: il y en a qui vont économiser sur le dos des autres. Jusqu'au jour où l'on se rendra compte qu'il vaudrait mieux revenir à la situation précédente...
Je sais, c'est une opinion personnelle (et politique), pas de la programmation web. Mais un peu de discernement ne fait pas de mal. Un produit comme SPIP qui se veut accessible et polyvalent doit-il à ce point faire table rase du passé et supprimer toute compatibilité avec une entité qui avait un sens, celui d'une certaine proximité/similitude géographique? (un peu tirée par les tifs parfois, j'admets.)
[...] Météofrance va rapidement se faire réprimander s'ils ne changent
pas,
c'est une question de temps.
Non, de géographie. Déjà rien que pour la Bourgogne, le climat est
différent entre le nord (plateau de Langres), l'ouest (Yonne, Nièvre),
le centre (Morvan) et le sud-est (val de Saône). Et en Franche-Comté
c'est encore autre chose puisque c'est le massif du Jura. Même genre de
remarque pour Champagne/Lorraine/Alsace ou l'Aquitaine du Pays basque au
Limousin...
Si on parle de météo, même les anciennes régions n'ont que peu d'intérêt, le temps a Lyon est toujours différent de celui de Grenoble. Pour le BonCoin, ils attendent que ça rentre dans les moeurs, j'imagine que ça casse des trucs dans leur système qu'ils vont mettre un peu de temps à corriger.
Perso je pense pas que les départements ou les régions ou même les pays n'aient vraiment une logique réelle en regard des gens et de la nature, tout n'est qu'incongruité administrative dans ce cas :-), mais bon ... c'est aussi une opinion personnelle !
Il n'y a pas que la météo. Par exemple le Bon Coin aussi a gardé le
découpage en anciennes régions...
Ces "grandes régions" ne sont qu'une incongruité administrative de plus.
On complique la vie de bien des gens (la preuve) sous prétexte
d'économies qui restent à prouver. Enfin, si: il y en a qui vont
économiser sur le dos des autres. Jusqu'au jour où l'on se rendra compte
qu'il vaudrait mieux revenir à la situation précédente...
Je sais, c'est une opinion personnelle (et politique), pas de la
programmation web. Mais un peu de discernement ne fait pas de mal. Un
produit comme SPIP qui se veut accessible et polyvalent doit-il à ce
point faire table rase du passé et supprimer toute compatibilité avec
une entité qui avait un sens, celui d'une certaine proximité/similitude
géographique? (un peu tirée par les tifs parfois, j'admets.)
Et il y a un souci bizarre, absolument tous les messages de ce fil (et de celui-là seulement) sont doublés pour chaque intervenant, pour ma part je ne fais que "répondre à la liste" sans personne en cc ni bcc ...
Le 26/11/2016 à 13:07, cam.lafit@azerttyu.net a écrit :
L'idée d'ajouter les régions manquantes et de passer en obsolétes les
anciennes (par exemple avec l'idée des grandes régions) pourrait
limiter la casse.
rien que pour la Bourgogne, le climat est différent entre le nord (plateau de Langres), l'ouest (Yonne, Nièvre),
> le centre (Morvan) et le sud-est (val de Saône). Et en Franche-Comté c'est encore autre chose puisque
c'est le massif du Jura. Même genre de remarque pour Champagne/Lorraine/Alsace ou l'Aquitaine du Pays basque au Limousin...
Cet exemple montre qu'il y a d'autres régions que administratives
Y a t il un outil pour gérer les "régions humaines ou géographiques"
qui souvent sont plus intéressantes dans la vraie vie ?
"Morvan" ou "Vallée du Mesvrin" ou "Massif Central" ou "Pays de Caux" ?
Voire "Grand sud", "Littoral armoricain" ?
Une colonne "statut" ou "type" pourrait servir à indiquer quelle sorte de région il s'agit
"administrative", "ancienne administrative", "géographique", "pays", etc...
Je crois aussi que supprimer l'ancien découpage gênera certains utilisateurs.
Exemple, si les nouvelles régions sont en places, les académies de l'Education Nationale sont encore sous l'ancien schéma.
Le 27/11/2016 à 11:29, Matthieu Marcillaud a écrit :
Ne serait-il pas plus indiqué de créer un niveau supplémentaire "grande
région", dont les régions précédentes ne seraient qu'un découpage
intermédiaire? Ça ne casserait rien et on garderait les compatibilités.
Oui, c'est vrai que je suis aussi partagé. Il me semble qu'il faudrait
conserver un moyen d'accès aux anciennes régions après cette mise à jour.
Ce que j'ai l'impression, c'est que même si juridiquement /
administrativement les nouvelles régions sont actées, présentes, il n'en
reste pas moins que les anciennes sont toujours utilisées. Et j'imagine
bien qu'on puisse vouloir les 2 usages sur un même site (ie: des filtres
géographiques par nouvelles régions / anciennes régions).
C'est vrai que je reste dans la supposition, mais bizarrement ça me gêne
de "perdre" cette info.
Ce n'est juste qu'un avis pour la discussion… ma foi peut m'importe ce
qui sera fait, c'est vrai que le plus important déjà est d'avoir accès
aux nouvelles régions !
Peut-être alors ce plugin devrait-il s'appeler territoires
administratifs plutôt que géographie, terme trop générique pour sa
vocation première assez stricte et son utilisation attendue, et qui
semble poser problème.
Rien n'empêche un autre plugin d'exploiter les données de celui-ci pour
constituer une base géographique plus large.
mes 2 écus au passage
fred
Le 28/11/16 08:35, JLuc a écrit :
Le 27/11/2016 à 19:41, Christian Marget a écrit :
rien que pour la Bourgogne, le climat est différent entre le nord (plateau de Langres), l'ouest (Yonne, Nièvre),
> le centre (Morvan) et le sud-est (val de Saône). Et en Franche-Comté c'est encore autre chose puisque
c'est le massif du Jura. Même genre de remarque pour Champagne/Lorraine/Alsace ou l'Aquitaine du Pays basque au Limousin...
Cet exemple montre qu'il y a d'autres régions que administratives
Y a t il un outil pour gérer les "régions humaines ou géographiques"
qui souvent sont plus intéressantes dans la vraie vie ?
"Morvan" ou "Vallée du Mesvrin" ou "Massif Central" ou "Pays de Caux" ?
Voire "Grand sud", "Littoral armoricain" ?
Une colonne "statut" ou "type" pourrait servir à indiquer quelle sorte de région il s'agit
"administrative", "ancienne administrative", "géographique", "pays", etc...
