Bonjour,
Le dimanche 8 février, je m’attaquais au portage de SPIP sous PostgreSQL.
SPIP 1.7
PostgreSQL 7.3.2p1
1 journée et demie de travail. En cherchant à minimiser les modifications.
Il faudrait que je cherche à :
Le dimanche 8 février …
Sent: Tuesday, February 10, 2004 12:24 AM
Ca fait un long dimanche ca …
Juste un petit retour d’experience sur ce genre de choses.
Idéalement, il faudrait séparer la construction de la base (qui peut avoir des syntaxes changeantes selon les bases) des inserts (normalement plus standardisables).
Le plus portable, à mon avis, c’est de faire des insert complet (en nommant les champs).
Il faut bien sur eviter le fonctions specifiques (du genre « insert or replace » => faire le delete avant puis le insert).
Par contre tu dis que GROUP BY n’est pas standard ?
il y a bien longtemps que je n’ai pas utilisé postgres, mais il me semble que ca passe.
Ca n’est pas du SQL/92 mais ca doit etre dans le SQL/99 ca non ?
ou c’est parce qu’il attend select *, chp1 group by chp1
Juste un conseil pour les dates, le mieux c’est de ne pas les mettre dans le insert (si elles sont toutes à 0000-00-00) et de definir la valeur par defaut (not null) dans la base.
J’ai deja experimenté du portage (pas de SPIP) vers un SQL Server, il attendait les dates au format francais !
Les formats different selon les produits et leur parametrage.
Coté chiffres dans les noms des champs, c’est effectivement un probleme quand ca commence par un chiffre sur de nombreuses bases, mais je n’ai pas eu de problemes avec des champs finissant par un chiffre, mais bon …
Je sais bien que ca n’est pas LE standard à respecter, mais passer par des drivers ODBC evite beaucoup de problemes.
En prenant un client Postgres (je n’en connais pas mais il doit y avoir l’equivalent de MySQLFront) et en connectant la base MySQL via ODBC, tu peux essayer de faire un import de base à base.
Je l’ai fait depuis Access sans souci, le script generé est assez propre, meme si ca ne regle pas tous les problemes.
Sinon Access le fait tres bien aussi(jouer avec des tables de differentes bases), mais tu ne peux pas recuperer le script qu’il genere(tu fais simplement un copier/coller), il faut ré exporter une fois toutes les tables recréées
Je vous souhaite bien du courage, ca n’est pas une chose facile.
J’espere egalement que vos remarques seront prises en compte pour une prochaine version (meme si le renommage des champs n’est pas une evidence pour les migration).
Je sais que SPIP est très intégré à MySQL et que c’est sans doute une force, mais pour déployer un SPIP en entreprise, il y a et il y aura souvent ce genre de contrainte.
Je ne suis pas un pro de PHP, mais il me semble qu’ADODB permet de faire à la fois l’abstraction necessaire à la portabilité et l’utilisation de fonctions specifiques aux bases, mais jusqu’à quel point …
Bon courage, @++
Pailloncy Jean-Gérard a écrit :
Le dimanche 8 février,
mon anniversaire !
je m’attaquais au portage de SPIP sous PostgreSQL.
ce SGBD est il disponible sur des hébergements grand public ?
JLuc