Bonjour,
Je voudrais savoir s'il existe une version de spip supportant postgresql ?
Après plusieurs recherches je suis tombé sur un projet qui avait commencé à
le faire mais cela semble être au point mort : le site ne marche plus....
Des infos ?
Bonjour,
Je voudrais savoir s'il existe une version de spip supportant postgresql ?
Après plusieurs recherches je suis tombé sur un projet qui avait commencé à
le faire mais cela semble être au point mort : le site ne marche plus....
Des infos ?
Olivier Sirven wrote:
Bonjour,
Je voudrais savoir s'il existe une version de spip supportant postgresql ? Après plusieurs recherches je suis tombé sur un projet qui avait commencé à le faire mais cela semble être au point mort : le site ne marche plus....
Des infos ?
le SQL est hardcodé tout partout dans Spip, et il utilise les finesses et spécialités de MySQL.
Par contre, il n'y a pas d'appel dircet aux function mysql_*, il y a un binding spip_* en prevision d'une abstraction, mais aussi pour faire du debug et du bench comme un sauvage.
La solution passera peut être par adodb qui servirait de couche d'abstraction avant la base.
M.
Plusieurs remarques sur cette question.
Un portage avait été partiellement réalisé pour la 1.7.
Il est décrit dans ce thread:
http://thread.gmane.org/gmane.comp.web.spip.devel/16655
En ce qui concerne la CVS actuelle, il faut distinguer 3 problèmes
pour les rapports entre Spip & PostGres:
1. la création des tables;
2. leur lecture à partir d'un squelette;
3. leur modification et les autres cas de lecture.
Pour le point 1, c'est à présent assez facile à faire:
les tables sont décrites sous forme de tableau PHP
(dans inc_serialbase et inc_auxbase)
et sont passées en argument de la fonction spip_create_table
qui construit la requête MySQL CREATE idoine.
Il suffit de donner une nouvelle version de cette fonction
pour se conformer à la syntaxe de PG (dire "serial" au lieu de "autoincrement" etc).
Pour le point 2, il y a maintenant 4 fonctions dans inc-calcul.php3:
function spip_abstract_select
function spip_abstract_fetch
function spip_abstract_count
function spip_abstract_free
qui réalisent les fonctions PHP/MySQL homonymes, et prennent comme dernier argument optionnel
le nom du serveur. S'il est absent, c'est le serveur standard. Si sa valeur est V,
ces fonctions passent la main aux fonctions spip_V_select, spip_V_fetch etc.
Donc si on définit spip_postgres_select etc, on a le portage pour les opérations de lecture.
J'ai fait l'essai avec un serveur postgres distant pour des boucles avec des critères simples,
sur des tables décrites comme au point 1. Ca marche, mais il faudrait regarder systématiquement
tous les critères pour assurer qu'il n'y aura pas d'erreur PG.
Pour le point 3, tout est à faire. En fait il faut réécrire la fonction spip_query_db définie dans inc_db_mysql. Il s'agit essentiellement de réécrire la requete UPDATE (plus qq DELETE).
Je ne peux pas le faire, mais je peux donner tout indication nécessaire si qq veut s'y coller,
voire modifier certaines séquences dans le CVS si ça améliore la portabilité générale de Spip.
Emmanuel