[migration] Passage à PG

Message par **sly** » 16 févr. 2013, 18:36

Je ne me rend pas forcément compte, mais la migration est pour l'instant faite ainsi :
1) était : mysql_* + base mysql + gis à la main foireux
2) devient : PDO + base mysql + un peu de gis foireux et un peu de gis avec mysql
3) passage par ? : PDO + base mysql + geophp
4) devrait finir par : PDO + base PG/GIS + gis avec PG ou geophp

Je ne me rend pas compte du boulot que représente 2+3 et de ce qu'on va pouvoir récupérer ou non pour finir par 4 au final.

Je me demande donc si ça ne vaut pas mieux de sauter directement sur 4 : c'est à dire migrer notre base mysql vers PG, retirer les champs/tables qui ne serviront plus. Constater que c'est cassé de partout, et réparé petit à petit en sachant qu'on est déjà sur l'environnement final.

Avantages que j'y vois : on est moins tenté dans 3 de faire "trop" de geophp alors que postGIS pourra nous en faire une partie directement par les requêtes, pour dom et yip qui ne connaissent pas encore trop les possibilités de postgis ça permet d'avoir tout de suite sous le plancher le bon accélérateur et résoudre nombre de problème de migration de fonction par des appels à postgis directement sans faire un détour, car le mysql ne le permettant justement pas, on est vite tenté de faire autrement.

Avis ?

Message par **sly** » 16 févr. 2013, 20:27

Dans l'objectif de tester cette migration my->pg, afin de voir à quelle sauce on va être mangé, j'ai trouvé un outil qui semble quasiment réussir à faire la migration tout seul et ça semble s'être plutôt bien passer (en apparence)

Par contre, même si la base est là, il n'y a quasiment rien qui marche, le forum à 5% le site à 10% bref, c'est pas gagné gagné, mais si on a la foi, et le courage ça pourra peut-être le faire.

Pour ne pas perturber yip dans son travail PDO+my, j'ai créé une nouvelle branche :
https://github.com/sletuffe/www.refuges ... gration-pg

Pour y passer avec git, on fait :
git checkout migration-pg
et hop.

Pour revenir à la branche principale :
git checkout master

Je ne compte pas trop avancer dans cette branche (sauf si vraiment bon résulats), c'est juste une manière de tester pour voir comment se comporterait wri avec PG

Point qui m'inquiète, même si phpBB dispose bien du support postgresql, ça ne passe pas comme une lettre à la poste, sans doute a-t-il été codé pour une vielle version et je ne saurais mesuré la tache de lui faire entendre raison

http://sly.refuges.info/news.php pointe sur la branche en question (full PG)

yip · Message par **yip** » 17 févr. 2013, 08:38

On savait que ce serait du boulot.

D'accord, on bascule, c'est la meilleure chose a faire maintenant
le gros du travail preparatoire pour la bascule est fait,
Ce sera plus rapide de chercher les bugs comme ca .
Mais avant, tu es sur des datatype ? on peut changer la primary key apres coup ? (autre posts)

Sly, je peux pas verifier là mais l'erreur vient quasi sur de la fonction UNIXTIMESTAMP qui est seulement du Mysql. j'ai pas trouvé de fonnction qui soit portable,donc j'ai ete obligé de laisser sachant que ca allait foirer..
ca fait partie des centaines de trucs qui vont foirer.
Heureusement, la fonction liste_comments est centralisée, avec une poignee d'autres, dans fonctions_BDD. c'est un systeme de Templates SQL, tu comprendra vite.
ca fait une dizaine de SQL en moins qui se balladent partout pour des taches identiques.
Apres faudra qu'on essaie d'utiliser les VIEW pgsql, mais pour le coup, pas portable contrairement a PDO.

"Ya plus gd chose qui marche'

ouep. du SQL a modifier, des quotes a virer (PG est dur avec les quotes

il y a pas 1 requete sur 3 qui va marcher ....
Mais chaque correction va nous rapprocher du but !

en tout cas chapeau pour l'import PG, ca permet d'avancer.

GIT:
désolé ca me dépasse. toujours des conflits de merge, toujours résolus tout seuls. je crois pas aux miracles. ya forcement de la perte de data qqpart ....
t'es sur que c'est une bonne idee de forker les git ? ma branche est maintenant "bossable", prete a migrer sur PG.

GIS/Geo
tu avais raison, geoPHP n'est pas vraiment pour nous.

Message par **sly** » 17 févr. 2013, 11:56

yip a écrit : D'accord, on bascule, c'est la meilleure chose a faire maintenant
le gros du travail preparatoire pour la bascule est fait,
Ce sera plus rapide de chercher les bugs comme ca .

Je le pense aussi, sinon on va recoder du spécifique my alors qu'on veut finir avec pg

yip a écrit : Mais avant, tu es sur des datatype ? on peut changer la primary key apres coup ? (autre posts)

Je n'ai rien vérifié, j'ai testé une migration, ça à l'air de marcher, je ne suis pas encore rentre dans les détails, mais c'est à faire, pour ne pas trouver plus tard qu'un type de données biscornues a été choisi par l'outil de migration que j'ai utilisé (mais que je ne connais pas).

yip a écrit : Sly, je peux pas verifier là mais l'erreur vient quasi sur de la fonction UNIXTIMESTAMP qui est seulement du Mysql. j'ai pas trouvé de fonnction qui soit portable,donc j'ai ete obligé de laisser sachant que ca allait foirer..

Pour le besoin des tests, j'ai commencé à transformer des UNIXTIMESTAMP en un truc pg (mais, là aussi, sans doute que pg) mais ça n'a pas réparé la page news complètement (y'a pas que ça)

Heureusement, la fonction liste_comments est centralisée, avec une poignee d'autres, dans fonctions_BDD. c'est un systeme de Templates SQL, tu comprendra vite.
ca fait une dizaine de SQL en moins qui se balladent partout pour des taches identiques.
Apres faudra qu'on essaie d'utiliser les VIEW pgsql, mais pour le coup, pas portable contrairement a PDO.

Je discute des 2 dans 2 autres posts

GIT:
désolé ca me dépasse. toujours des conflits de merge, toujours résolus tout seuls. je crois pas aux miracles. ya forcement de la perte de data qqpart ....
t'es sur que c'est une bonne idee de forker les git ? ma branche est maintenant "bossable", prete a migrer sur PG.

Jolis graphiques pour comprendre ce qui se passe avec git :
https://github.com/sletuffe/www.refuges.info/network

Y'a pas de problème, on utilise toujours tous les 2 la branche principale sur laquelle tu bosses appelée "master", mais si tu es obligé de faire un "merge" réguliers, c'est parce que, je pense, avant de commencer à bosser, tu devrais te synchroniser avec ce que j'ai fais. Là, tu dois commencer à coder, puis faire un "push" ensuite et il gueule que t'es pas synchro avec la version en ligne, donc obligé de merger.

Récapitulatif avec séquence probable de ce qu'il faudrait faire :
1) il est 18h00 sly bossant de jour, il fait un git pull pour être synchro
2) sly code et il fait des "git push" toutes les 30mn environ. A 20h00, il a fini, il fait un dernier git push pour mettre son travail (qui marche à moitié) en ligne
3) il est 1h du matin, yip commence. Il devrait très fortement faire un git pull pour être synchro avec la version de sly
4) il code est choisi soit des git push réguliers soit un seul git push final

GIS/Geo
tu avais raison, geoPHP n'est pas vraiment pour nous.

A bon ? je pensais qu'il nous ferais au moins les exports gps/gml/kml non ?

Message par **sly** » 17 févr. 2013, 13:07

Voilà qui est donc passé à postgresql pour la dernière version master sur github.

Et j'ai dû corriger mon premier merge conflictuel ;-)
Trop facile !

Bref, pensez bien à un "git pull" afin de synchroniser la dernière version, et avant pour la correction de bug petit à petit.

J'en profite pour supprime ma branche pg qui ne sert plus (cf graph toujours pour avoir une vue d'ensemble de ce qui se passe, même si ça change rien au final)
https://github.com/sletuffe/www.refuges.info/network

Message par **Dominique** » 17 févr. 2013, 14:14

GIT:
désolé ca me dépasse. toujours des conflits de merge, toujours résolus tout seuls. je crois pas aux miracles. ya forcement de la perte de data qqpart ....
t'es sur que c'est une bonne idee de forker les git ? ma branche est maintenant "bossable", prete a migrer sur PG.

Ne pas non plus en attendre des miracles.
Je ne connais pas de méthode pour tout faire évoluer simultanément à 2.

Désolé pour le reste, pas assez dispo pour suivre

yip · Message par **yip** » 17 févr. 2013, 22:29

sly a écrit : Pour le besoin des tests, j'ai commencé à transformer des UNIXTIMESTAMP en un truc pg (mais, là aussi, sans doute que pg) mais ça n'a pas réparé la page news complètement (y'a pas que ça)

Bon Courage ! On peut aussi gerer les timestamp en PHP et enregistrer des Int, au moins c'est portable, mais ca fait pas mal de taf...

sly a écrit : GIS/Geo
tu avais raison, geoPHP n'est pas vraiment pour nous.
A bon ? je pensais qu'il nous ferais au moins les exports gps/gml/kml non ?

A la reflexion, si c'est juste pour ça, comme il est pas capable de faire l'interface entre SQL et OL ... rajouter une brique juste pour ça, ça m'embete un peu. je me disais autant essayer de faire cracher du GPX a OpenLayers. Dominique , tu crois qu'OL est capable de faire un dump GPX de ce qu'il a reçu ? Si c'est possible, ca peut etre plus simple que geophp. ou pas , aucune idée.

GIT, a c'est pour ca ... le git pull faut le faire au debut ....

Message par **sly** » 17 févr. 2013, 23:14

yip a écrit : Bon Courage ! On peut aussi gerer les timestamp en PHP et enregistrer des Int, au moins c'est portable, mais ca fait pas mal de taf...

Oulla, surtout pas malheureux ! Sinon on peut se gratter pour toutes les opérations sur les dates. Et trouver tous les commentaires ayant eu lieu un mardi, je te raconte pas le binz avec des int (nb de seconde depuis epoch). La base va nous stoquer un "date" et on va bien réussi à lui faire convertir ça en timestamp unix, et tant pis si on doit être spécifique pg, c'est pas non plus comme si on voulait passer sous oracle dans 6mois ;-)

D'ailleurs hop :
extract('epoch' from date) as unix_ts
et voilà.

Pour la question WFS, je n'ai pas assez d'expérience pour répondre si ça peut être ou non la bonne voie pour wri.

Dans les assez bonnes nouvelles, après un long combat de migration my->pg j'ai refais plusieurs fois la conversion car des types n'avaient pas été bien converti et ça expliquait nombre de bug sur le site, donc de nouvelles choses marchent et surtout, phpBB semble fonctionner avec PG. Il reste un bug, et peut-être d'autres, mais sachant que je n'ai toujours pas trifouillé le code de phpBB je suis plutôt confiant.

Message par **sly** » 17 févr. 2013, 23:43

Bon, j'ai sans doute crié victoire trop vite mais j'apprends au moins à chercher les problèmes aux bons endroits.

Pour trouver les problèmes liés à une requetes SQL :
tail -f /var/log/postgresql/postgresql-9.1-main.log
(faut passer root)
postgresql cause pas mal est indique assez bien de quel problème il s'agit

Pour un pépin php :
tail -f /var/log/apache2/errors-sly.refuges.info.log

yip · Message par **yip** » 18 févr. 2013, 22:54

Merci pour le debuggage, ce sera utile !

Concernant la Database, j'ai 2 questions:

- Les primary key en integer+nextval ne sont pas standard PG (il me semble). est-ce temporaire ou definitif ? (normalement c'est le type serial, je connais pas la tambouille interne de PG mais (si) on a besoin des sequences de primary key et ça apporte des differences ? ou pas ?)
actuellement, notre code utilise des sequence de primary key.
Je me dis qu'il vaut mieux soulever le point assez tot pour faire un truc dans les normes avant qu'il y ait tout a refaire ...

-Est-ce possible d'installer PostGIS 2.0 ? La difference que j'ai vu pour l'instant est qu'il gere les colonnes geometry en "transparent", ce qui n'est pas le cas de postgis 1.5:

De ce que j'ai compris:
>en postgis1.5: faut faire AddGeometryColum pour ajoute une geom. sinon, la table systeme "geometry_column" n'est pas mise a jour et tout ce qui est GIS part a la trappe. (me suis fais avoir plusieurs fois avec phppgmyadmin)
Cette table systeme est a mettre a jour a la main des fois (comme lors de suppression de colonne) il y a peut etre des schemas associes mais je n'y comprends rien.
>en postgis 2: un ADD COLUMN type POINT tout con (SQL ~Standard) va se demerder tout seul pour faire ce qu'il faut. idem le DROP

Des colonnes GIS on va pas en faire tous les jours, alors pourquoi se prendre la tête ...
Parce que du coup, les VIEWS (standard SQL ANSI) ne peuvent pas faire du spatial correctement.
à moins de rajouter une surcharge de code SQL illisible et obscur.
et rajouter du code là ou on pourrait s'en passer, j'aime pas ça du tout

(malgré les apparences hein

)

postgis 2.0 peut s'installer sans changer de PostgresQL apparement. Malheureusement, debian, comme d'hab, a 10 mois de retard

edit: pour postgis 2, c'est pas la mere a boire non plus , t'embetes pas

edit2: type serial est strictement identique ...

Code : Tout sélectionner

CREATE TABLE tablename &#40;
    colname SERIAL
&#41;;

is equivalent to specifying&#58;

CREATE SEQUENCE tablename_colname_seq;
CREATE TABLE tablename &#40;
    colname integer NOT NULL DEFAULT nextval&#40;'tablename_colname_seq'&#41;
&#41;;
ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname;

La prochaine fois je regarderais la doc avant...

edit 3: Actuellement, les colonnes "geometrie_points.." ne sont pas des colonnes de type GIS, donc calculs impossible, car elles ne sont pas dans la table systeme "geometry_columns" : elles ont surement été rajoutées avec l'interface phpgpadmin. l'interface ne le fait pas. faut vraiment faire le rajout en SQL avec AddGeometryColumn.
ce genre de truc n'arriverait plus en postgis 2 mais bon, on va pas en faire tous les 4 matins non plus ...
Pour l'indexation en revanche, il y a une indexation specifique GIS ? et si oui, est-ce que le bricolage de table geometrey_column suffit a l'activer ?

Message par **sly** » 19 févr. 2013, 10:47

yip a écrit :
- Les primary key en integer+nextval ne sont pas standard PG (il me semble). est-ce temporaire ou definitif ? (normalement c'est le type serial

Je crois que "serial" est juste un raccourcis dans la commande pour créer la table qui fait exactement : un integer + une séquence

Sinon, de manière général, le schéma n'est pas définitif du tout, j'ai passé ça par une moulinette qui m'a fait My->PG et qui m'a beaucoup gagné de temps, mais je suis quand même obligé de faire des ajustements, ma tambouille de migration my->pg (hors gis) est là :
https://github.com/sletuffe/www.refuges ... my-vers-pg
Les questions GIS pure sont complétées dans ton fichier
https://github.com/sletuffe/www.refuges ... SEZMOI.txt

-Est-ce possible d'installer PostGIS 2.0 ?

Pas facile car debian en retard ;-) de plus, c'est assez récent postgis 2, je préfère attendre d'en voir vraiment les avantages. (J'ai plein de testeurs chez osm qui testent pour moi) mais osm france continue toujours à utiliser postgis 1.5 car jugé plus stable.

De ce que j'ai compris:
>en postgis1.5: faut faire AddGeometryColum pour ajoute une geom. sinon, la table systeme "geometry_column" n'est pas mise a jour et tout ce qui est GIS part a la trappe. (me suis fais avoir plusieurs fois avec phppgmyadmin)

Tu me fous le doute maintenant. Je me rappel en effet, il fût un temps, ou je devais faire ce AddGeometryColum pour osm. Là, par exemple, pour points_gps, j'ai oublié de le faire... et rien n'a été supprimé pour autant et mes requêtes spatiales marchent :

Code : Tout sélectionner

select nom,st_astext&#40;geometrie_point_gps&#41;,name 
from 
  points,points_gps,osm_polygon 
where 
  id_point=5 and 
  points.id_point_gps=points_gps.id_point_gps and
  st_contains&#40;way,geometrie_point_gps&#41;;

Mais je suppose fort que quelque chose va foirer. Je recommande donc de le faire, et tant pis si c'est à la main, après tout, on a que 2 colonnes à créer à la main, ça devait aller ;-)

Je propose : on avance comme on est, si vraiment ça nous manque, je me creuserais la tête pour faire manger postgis 2.0 à debian.

edit 3: Actuellement, les colonnes "geometrie_points.." ne sont pas des colonnes de type GIS, donc calculs impossible, car elles ne sont pas dans la table systeme "geometry_columns"

En effet, je ne suis pas passé par le AddGeometryColum (j'ai oublié) et j'ai donc créé "à la main" et j'en ai oublié la moitié. En fait, j'ai oublié de déclarer le SRID (système de projection) souhaité pour la colonne, ce que je viens de faire. Mais je pense que le mieux c'est de passer par AddGeometryColum et d'ajouter ensuite l'index qui n'est pas créé on dirait.

Je vois d'ailleurs qu'on a tout les deux créé une colonne pour la géométrie mais que la tienne elle marche ;-) (il lui manque juste l'index)
Comme tu veux pour le nom d'ailleurs, tant qu'on pense bien à noter la procédure et la liste des requêtes (si possible pour éviter de faire clic clic dans phppgadmin) car il faudra la refaire quand on repartira de l'export mysql.
Pour la table polygones, qui semble plus ardue à reconstruire, je propose qu'on s'occupe d'elle, et une fois fait, on en fait un dump qu'on rechargera à la fin sinon on va galérer à tout refaire alors que refuges.info (en prod) a peu de chance de voir ces polygones bouger.

Les conversions à faire sont : les massifs niveau 1, (alpes/pyrénnées/...) les massifs, les cartes suisses (ou on peut repartir de ça : https://github.com/sletuffe/www.refuges ... sstopo.txt)

Pour les pays, régions, départements, réserves naturelle, je vais tout refaire avec osm, et ce n'est de toute façon pas vital pour que refuges.info puisse tourner (enfin, je crois)

Pour l'indexation en revanche, il y a une indexation specifique GIS ? et si oui, est-ce que le bricolage de table geometrey_column suffit a l'activer ?

non, ni en postgis 2.0 d'ailleurs, dans postgresql, les indexes sont toujours à créer à la main. D'ailleurs, à noter que même avec postgis 2.0 il faut quand même faire le AddGeometryColum et quand même créer l'indexe.
Syntaxe :
CREATE INDEX polygones_geometrie_polygone ON polygones USING gist (geometrie_polygone);
polygones_geometrie_polygone c'est son nom, et on le choisi comme on veut, mais la convention habituelle est "$table_$champ"

Message par **sly** » 19 févr. 2013, 11:13

Punaise, j'ai pas gaffe que tu avais vachement avancé sur les colonnes geom. Je vire les miennes donc, et j'ajoute les indexes aux tiennent. Et je note ça dans GIS_LISEZMOI.txt.

J'en profite pour vider les champs inutiles car remplacés par le champ geom.

Dans polygones, il reste un champ "linestring" c'était juste temporaire ?

J'ai vu que tu avais créé une table points_gps_sans_poly tu l'a noté ta procédure pour vider tout ce qui est sans rapport avec les polygones ?

yip · Message par **yip** » 19 févr. 2013, 12:25

ah, bah non, je pensais que tu bossais sur les geometrie_table alors pour pas perturber, je te laissais faire, et j'ai fais les miennes

et puis elles etaient pas pretes, tu as vu le probleme du AddGeometryColumn, de postgis1.5 et postgis2 tout ca ...

quand tu veut on peut nettoyer tout ce qui traine (dont linestring) et renommer.

Message par **sly** » 19 févr. 2013, 13:09

yip a écrit :ah, bah non, je pensais que tu bossais sur les geometrie_table alors pour pas perturber, je te laissais faire, et j'ai fais les miennes

Comme les tiennes ont des polygones, je prends ;-)

quand tu veut on peut nettoyer tout ce qui traine (dont linestring) et renommer.

Je vire le linestring. Pour ce qui est de renommer, avec nom long, je ne sais plus où j'en suis car je trouve ça pratique car court ;-)
bref, fait comme tu veux, l'un comme l'autre me va, l'histoire de pouvoir récupérer les deux géométries d'un coup dans un objet php (sans colision de nom) n'ayant presque aucune chance de se produire il me semble que nom court ou nom long = kif kif bourrique

Message par **Dominique** » 19 févr. 2013, 18:44

yip a écrit :(OL officiel car j'ai pas réussi a ré-activer les fonctions du OL custom)

Envoie moi le test correspondant. Chaque fois que tu trouves qquchose. Il n'y a aucune raison pour que ça ne marche pas (en ajoutant les bons modules)
Ceci, non dans l'intérêt de tes tests, mais dans celui de la stabilité de ma librairie