[migration:en cours] Migration vers postgresql + php 5.4.4

Message par **sly** » 13 févr. 2013, 18:52

Sujet très très technique ;-)

Le site refuges.info va donc tenter de disposer de nouvelles bases logiciels :
- php 5.4.4
- postgresql 9.1 + postgis 1.5

Dans le but d'obtenir de nouvelles fonctionnalités plus simples à coder.

Voici pour les présentations, rentrons dans le fil du sujet, pour les autres programmeurs de refuges.info.

Je viens de créer une "copie" de refuges.info que l'on peut voir ici :
http://n.refuges.info

On reste avec mysql (5.5) pour l'instant, mais on passe bien à php 5.4.4 (une chose à la fois, une classe de bug à la fois)

Pour mes amis développeurs, les codes d'accès restent inchangés.

Le phpmyadmin se trouve désormais ici : http://n.refuges.info/phpmyadmin/
le serveur ftp ou sftp est : n.refuges.info
et le code est maintenant sous contrôle de source git, et la version publique est là : https://github.com/sletuffe/www.refuges.info

Si vous êtes encore dispo pour une réunion ce soir sur ce thème, on pourra parler de comment s'organiser au niveau code, et trouver le bon compromis entre usine à gaz et un minimum de suivi (retour arrière, détection de bugs, bref, ce que sait faire git quoi)

En ce qui concerne postgresql, je suis en train de le mettre en place, mais plutôt que tout faire en même temps je suggère étape par étape. Un avis ?

dominique semble habitué à cette méthode de travail alors que moi je débute juste, s'il veut nous donner un cours à son tour ;-)

Message par **sly** » 13 févr. 2013, 23:49

J'ajoute que le phppgadmin pour manipuler la base postgresql est ici :
http://n.refuges.info/phppgadmin/
(identifiants identiques à ceux de mysql)

Notez par contre que je n'ai jamais utilisé, je ne sais donc pas ce que ça vaut.

Ayant plus l'habitude de faire du pgsql à la main ;-) (mais c'est pas toujours simple)

yip · Message par **yip** » 14 févr. 2013, 08:51

toi qui t'y connais en PGsql,

j'ai commencé a tout passer sur PDO et tant qu'a faire j'ai re ecrit 2 3 requetes avec des fonctions Spatial qui seront compatibles et portables
(fct points, fct polygones et fct bdd a peu pres terminées avec noir de bugs

)

On utilise quelques trucs MySQL qui ne passeront pas en PG, malgré la couche d'abstraction PDO, tu as peut etre une idee :

- SQL_CALC_FOUND_ROWS, utilisé par la mega-requete liste_points n'existe pas en PG
- PDO::rowCount est aussi pas fiable, il parait
- UNIX_TIMESTAMP va falloir remplacer par un subquery?
- PDO::lastInsertID est annoncé comme merdique et j'ai rien compris au "INSERT INTO ... RETURNING ID"

Voila, a part le timestamp et l'insertID qui sont gérables, mais pas portables, pour les autres j'ai pas vraiment trouvé de solution sur PG.

On peut surrement pas se permettre de lancer une 2e requete juste pour faire un Count(*), c'est des requetes de ouf qui bouffent du CPU au p'tit dej...

Pour le contexte, c'est dans ~yip/wri/modeles/fonctions_points, grep "FIXME POSTGRESQL"

c'est en plein chantier, donc pas de git commit.
Cette plateforme de dev, c'est un panard c'est dingue !

yip dodo

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

yip a écrit : On utilise quelques trucs MySQL qui ne passeront pas en PG, malgré la couche d'abstraction PDO, tu as peut etre une idee :

Je m'y attendais un peu, je ne saurais dire si ça n'existe ou pas en PG ou si c'est PDO qui nivèle par le bas (ce que je crains en général avec les abstractions)
Mais je vais tester moi aussi pour voir si je peux trouver correctif, palliatif, ou autre

Pour le contexte, c'est dans ~yip/wri/modeles/fonctions_points, grep "FIXME POSTGRESQL"

c'est en plein chantier, donc pas de git commit.

En fait, à mon avis, mais à discuter, c'est justement tout l'intérêt de publier sur git, et tant pis si c'est buggé. Sans quoi, si je veux moi aussi tester et corriger des bugs, je suis obligé d'aller chez toi, ou alors je risque de créer des problèmes de conflits.

La règle du "c'est sur github donc ça marche" ne me semble pas nécessaire du tout.
En plus, comme c'est en gros chantier, vu qu'on l'a indiqué partout, ça ne sera pas choquant si ça merdoit.

Je suggère donc de suivre le bon vieux adage du libre : "release quick, release often" ainsi, les autres peuvent hacker sur la base de ce que tu as déjà fait.
Et si vraiment l'un d'entre nous veux bosser sur un truc sans rapport avec la migration PG (genre, cosmétique dans OL) alors il reste toujours possible de créer une "branche"

yip · Message par **yip** » 15 févr. 2013, 08:28

Sly, comme tu l'a conseillé, j'ai uploader mon bazar inopérant.

A la reflexion, le plus gros pb sera surement que PG est moins permissif que MySQL. par exemple numero_point == '123' (INT = STRING) ne passera plus car "type mismatch". Difficile de les voir partout, j'essaie de centraliser le SQL un peu avec PDO, a l'image du modele MVC.

Une question pour Dominique et Sly:

On pourrait inclure le mod GeoPHP ? https://github.com/phayes/geoPHP

Maintenir tout ce qui est exportations maisons me fait peur.

La technique "a la mano" risque de montrer ses limites quand on aura des vrais objets GIS à traiter (j'en rencontre là ....).

si on adopte geoPHP, on supprimerai les formats qu'ils ne supporte pas pour ne conserver QUE les siens, comme ça on gagne un max de code et de maintenance.
Ca nous permettrai de supprimer toutes les fonctions d'exports maison, et de faciliter l'interface entre OL et postGIS (en WKB ? )

Ca ferait le 3e mod externe, apres phpBB et OL, en essayant de le garder "intact" (on dis ça au début

)

qu'en pensez-vous ?

Message par **Dominique** » 15 févr. 2013, 08:45

sly a écrit :La règle du "c'est sur github donc ça marche" ne me semble pas nécessaire du tout.
En plus, comme c'est en gros chantier, vu qu'on l'a indiqué partout, ça ne sera pas choquant si ça merdoit.

La règle n'est pas "c'est sur github donc ça marche": on y met toutes les étapes et c'est la dernière qui marche qui sera utilisée pour mettre sur le serveur de production, pas la dernière en ligne
Rien n'empêche de reprendre la rel-2, d'en faire un fork, ...

sly a écrit :Je suggère donc de suivre le bon vieux adage du libre : "release quick, release often" ainsi, les autres peuvent hacker sur la base de ce que tu as déjà fait.
Et si vraiment l'un d'entre nous veux bosser sur un truc sans rapport avec la migration PG (genre, cosmétique dans OL) alors il reste toujours possible de créer une "branche"

Oui, surtout minimiser les merge. C'est joli sur le papier, mais ça be résoudra pas tout:
Si JM fait de grosses modifs sur un bout de code et livre après 3 mois, ma petite correction de bug sera juste perdue.
Pour moi, on upload dés qu'on a quelque chose d'à peu prés stable et propre (on devrait y arriver au mois 1 fois par jour) même si ça reste à valider dans l'ensemble

Message par **sly** » 15 févr. 2013, 10:49

yip a écrit :Sly, comme tu l'a conseillé, j'ai uploader mon bazar inopérant.

Super !
ça en fait des choses, bien, je vais avoir un point de repère sur comment tu vois les choses concernant l'abstraction, le rangement, etc.
Bien que je ne puisse promettre d'être très dispo

A la reflexion, le plus gros pb sera surement que PG est moins permissif que MySQL. par exemple numero_point == '123' (INT = STRING) ne passera plus car "type mismatch". Difficile de les voir partout, j'essaie de centraliser le SQL un peu avec PDO, a l'image du modele MVC.

PG est en effet plus tatillon avec un typage fort contrairement à mysql qui est plus ollé ollé. Ce qui nous promets en effet de nombreux petits ajutements.

On pourrait inclure le mod GeoPHP ? https://github.com/phayes/geoPHP

Maintenir tout ce qui est exportations maisons me fait peur. :|
La technique "a la mano" risque de montrer ses limites quand on aura des vrais objets GIS à traiter (j'en rencontre là ....).

si on adopte geoPHP, on supprimerai les formats qu'ils ne supporte pas pour ne conserver QUE les siens, comme ça on gagne un max de code et de maintenance.
Ca nous permettrai de supprimer toutes les fonctions d'exports maison, et de faciliter l'interface entre OL et postGIS (en WKB ? )

Ca ferait le 3e mod externe, apres phpBB et OL, en essayant de le garder "intact" (on dis ça au début ;) )

qu'en pensez-vous ?

Je n'y vois pas d'inconvénients, en plus ça semble être capable de parler à postGIS d'après la doc, si vraiment ça nous permet de gagner du temps pour sortir et rentrer des géométries, moi je dis pas de problème.
Je suggère de faire un premier essai (je ne sais quel export tu voudrais traiter) d'abord afin de bien voir avantages et inconvénients du bidule. Sur le papier ça peut-être chouette, et après, quand on veut exporter un kml par catégories, on découvre que le truc ne sait pas faire.

Mais au début, j'étais dans l'idée que tout ce qui est transfert polygone vers OL on allait le faire directement en WKB (ce qui est le facile à sortir de postGIS) et qui à l'avantage d'être concis, compris par OL. Au défaut d'être moins flexible : WKB c'est une géométrie et c'est tout, les attributs sont à transférer autrement.