[spip-dev] SPIP pour PostgreSQL aka PGSPIP

Dev
1

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,
une version initiale basée sur SPIP 1.7 est au point, et elle marche.
Elle sera dispo d'ici qq jours, ce WE par exemple ;-).

Pour émuler les fonctions Mysql, un certain nombre de choses sont
nécessaires :
- Existence du langage Pl/pgsql pour les triggers et les opérateurs
(donc il faut être admin Postgres)
- la procédure d'install automatique de SPIP n'a pas été reprise, pour
les raisons évoquées ci dessus.
- donc la config finale (inc_connect.php3 )doit se faire à la mano ...
:frowning:

Cette version contient les patches pour PHP5, car le seul hébergeur
gratuit en PHP+Pg est en en PHP5 ...

C'est en prod ici et les sources seront uploadées :

http://patman.dotgeek.org/pgspip/

Merci de me remonter les bugs et les boulettes diverses observés en
installation et en fonctionnement.

PUB: J'ai réalisé le portage de SPIP sous PostgreSQL durant mon temps de
travail pour la société Cosmosbay~Vectis.

2

Salut,

Plusieurs choses me viennent à l'esprit :
- pourquoi ne pas avoir modifier l'installation de spip pour créer la table,
les triggers et les fonctions qui vont bien ?
- tous les portages que j'ai vu éliminaient systèmatiquement mysql de
spip....pourquoi ne pas simplement rajouter le support de postgresql en
laissant *aussi* le support de mysql ? On pourrait alors imaginer
l'intégration de ces modifs au cvs ?

3

Salut,

Plusieurs choses me viennent à l'esprit :
- pourquoi ne pas avoir modifier l'installation de spip pour créer la table,
les triggers et les fonctions qui vont bien ?

Hello,
Ca aurait été possible mais je suis un grand fainéant !! :wink:

Un autre détail moins reposant :
- Il faut changer de login postgreSQL en cours d'installation :
Créer la base spip (et éventuellement le user SPIP sous postgres) puis
instancier le langage pl/pgsql dans la base.
- Puis créer les tables et les fonctions sous l'ID non privilégiée

Mon idée de base étant que les personnes voulant utiliser postgreSQL ont
des raisons de le faire et donc des compétences SQL, passer un script ne
devrait pas leur poser de pb majeur. Du coup, j'ai fait une petite doc
on-line.

- tous les portages que j'ai vu éliminaient systèmatiquement mysql de
spip....pourquoi ne pas simplement rajouter le support de postgresql en
laissant *aussi* le support de mysql ?

le support de MySQL est conservé, j'ai créé un fichier inc_db_pgsql.php3
qui se charge du bric-à-brac de conversion.
Donc "a priori" ça devrait pouvoir toujours marcher avec MySQL.
La seule raison que ça soit en échec c'est que j'ai été obligé de
modifier quelques requêtes qui n'étaient vraiment pas conformes au SQL.
A voir si MySQL supporte des choses au standard SQL.

On pourrait alors imaginer
l'intégration de ces modifs au cvs ?

Ca serait vraiment bien, j'ai essayé d'être le moins intrusif possible
dans le code SPIP.
Je peux envoyer un diff pour que le team SPIP inspecte mes modifs SQL
dans le code SPIP.
A voir si il n'y a pas eu trop de modifs depuis la 1.7 (je crains le
contraire !)

PGSPIP: http://patman.dotgeek.org/pgspip/

4

Mon idée de base étant que les personnes voulant utiliser postgreSQL ont
des raisons de le faire et donc des compétences SQL, passer un script ne
devrait pas leur poser de pb majeur.

Bah non, on peut vouloir utiliser une base PG écrite par qq d'autre.

Du coup, j'ai fait une petite doc
on-line.

Tu parles de ça:
http://patman.dotgeek.org/pgspip/article.php3?id_article=1
ou bien y a-t-il qqch de plus détaillé qq part ?
Les commentaires dans inc_db_pgsql.php3 sont plus ce dont j'aurais besoin
pour l'intégration au CVS, mais en plus systématique dans la description des pbs rencontrés.

La seule raison que ça soit en échec c'est que j'ai été obligé de
modifier quelques requêtes qui n'étaient vraiment pas conformes au SQL.
A voir si MySQL supporte des choses au standard SQL.

On pourrait alors imaginer
l'intégration de ces modifs au cvs ?

Ca serait vraiment bien, j'ai essayé d'être le moins intrusif possible
dans le code SPIP.
Je peux envoyer un diff pour que le team SPIP inspecte mes modifs SQL
dans le code SPIP.

oui je suis preneur

A voir si il n'y a pas eu trop de modifs depuis la 1.7 (je crains le
contraire !)

Il y a plutot eu un effort de rationnalisation et d'abstraction,
je pense qu'un portage sur la CVS soit plus facile que sur la 1.7.

      Emmanuel

5

> Mon idée de base étant que les personnes voulant utiliser postgreSQL
> ont
> des raisons de le faire et donc des compétences SQL, passer un script
> ne
> devrait pas leur poser de pb majeur.

Bah non, on peut vouloir utiliser une base PG écrite par qq d'autre.

Je suis d'accord :wink:
J'ai déjà réaliser les modifs sur la version cvs pour un installeur proposant
le choix entre mysql et postgres. Si cela t'interesse aussi, je te le donne
bien volontier. Pour info, ma version de inc_db_pgsql.php3 est commentée.

Il y a plutot eu un effort de rationnalisation et d'abstraction,
je pense qu'un portage sur la CVS soit plus facile que sur la 1.7.

Ou mais il y a quand même beaucoup de requêtes à modifier :wink:
En fait voilà ce que je suis en train de faire pour mon portage :
si le serveur sql est défini à autre chose que mysql, une variables globale
est définie pourtant le nom du driver : par exemple pgsql. Cette variable est
accessible via $GLOBALS['db_driver'].
Cela permet, pour chaque requête posant problème, d'écrire une autre version
sans pour autant effacer la requête mysql.
En revanche j'avoue ne pas trop avoir vu l'abstraction du sql :wink:
tu m'avais parler des function "spip_abstract_select" et consors mais je ne
les vois nul par de le code...il s'agit toujlours d'appel à spip_query et des
copains....donc j'imagine que je n'ai pas dû bien comprendre comment cela
marchait ?

6

J'ai déjà réaliser les modifs sur la version cvs pour un installeur proposant
le choix entre mysql et postgres. Si cela t'interesse aussi, je te le donne
bien volontier.

oui, d'accord.

Pour info, ma version de inc_db_pgsql.php3 est commentée.

c'est ce que je faisais remarquer, mais y a-t-il + des commentaires plus généraux qq part ?

Il y a plutot eu un effort de rationnalisation et d'abstraction,
je pense qu'un portage sur la CVS soit plus facile que sur la 1.7.

En revanche j'avoue ne pas trop avoir vu l'abstraction du sql :wink:
tu m'avais parler des function "spip_abstract_select" et consors mais je ne
les vois nul par de le code...

Je parle de la CVS, dans inc-calcul.php3

      Emmanuel

7

oui, d'accord.

je t'envoie ça ce soir

c'est ce que je faisais remarquer, mais y a-t-il + des commentaires
plus généraux qq part ?

c'est à dire ? de façon générale j'ai commentée toutes mes modifs

> En revanche j'avoue ne pas trop avoir vu l'abstraction du sql :wink:
> tu m'avais parler des function "spip_abstract_select" et consors mais
> je ne
> les vois nul par de le code...

Je parle de la CVS, dans inc-calcul.php3

J'avais bien compris mais je ne vois pas d'appel à ces fonctions ?

8

c'est ce que je faisais remarquer, mais y a-t-il + des commentaires
plus généraux qq part ?

c'est à dire ? de façon générale j'ai commentée toutes mes modifs

oui, mais une nomenclature de toutes les formes posant pb ?

En revanche j'avoue ne pas trop avoir vu l'abstraction du sql :wink:
tu m'avais parler des function "spip_abstract_select" et consors mais
je ne
les vois nul par de le code...

Je parle de la CVS, dans inc-calcul.php3

J'avais bien compris mais je ne vois pas d'appel à ces fonctions ?

??? Il y en a une palanquée dans inc-calcul-outils,
plus celles générées par le compilateur dans inc-compilo.

      Emmanuel

9

Ba je veux bien commenter toutes les constructions sql spécifiques à
mysql mais cela risque d'être un peu long....le plus simple est encore
de comparer la requête mysql avec la requête postgres située juste en
dessous dans le code non ?

En ce qui concerne les abstracts ca va mieux en regardant les fichiers
inc-calcul-outils et inc-compilo :wink:
En revanche j'ai toujours une question :
D'après ce que je vois dans inc-html-squel.php3, le serveur qui va être
utilisé dans les abstracts est défini dans la balise de
boucle....pourquoi ne pas utiliser la conf générée à l'install (ce qui
permettrait de ne pas multiplier la syntaxe des squelettes) ?
Par exemple si mon type de serveur est stockée dans
$GLOBALS['db_driver'], on pourrait envisager de l'utiliser dans les
fonctions abstract s'il est défini, non vide et que le paramètre
$serveur passé à la fonction est vide....qu'en penses-tu ?

En ce qui concerne le fichier que je t'ai promis, j'aimerai bien en fait
attendre d'avoir fini de faire mes corrections pour t'envoyer un diff
globale d'un coup....à moins que tu préfères petit à petit ? Bref dis
moi ce que tu préfères....

10

En ce qui concerne les abstracts ca va mieux en regardant les fichiers
inc-calcul-outils et inc-compilo :wink:
En revanche j'ai toujours une question :
D'après ce que je vois dans inc-html-squel.php3, le serveur qui va être
utilisé dans les abstracts est défini dans la balise de
boucle....pourquoi ne pas utiliser la conf générée à l'install (ce qui
permettrait de ne pas multiplier la syntaxe des squelettes) ?
Par exemple si mon type de serveur est stockée dans
$GLOBALS['db_driver'], on pourrait envisager de l'utiliser dans les
fonctions abstract s'il est défini, non vide et que le paramètre
$serveur passé à la fonction est vide....qu'en penses-tu ?

Le code en question a une fonctionnalité que tu n'as pas vue:
pouvoir utiliser PLUSIEURS serveurs dans une même config.
Dans une BOUCLE à syntaxe usuelle, c'est le serveur par défaut
(celui de inc_connect) sinon le nom explicitement donné dans la balise
référence implicitement une paire de fichiers
(inc_connect-pgsql.php3 inc_db_pgsql.php3)
permettant de faire les requetes.

En ce qui concerne le fichier que je t'ai promis, j'aimerai bien en fait
attendre d'avoir fini de faire mes corrections pour t'envoyer un diff
globale d'un coup....à moins que tu préfères petit à petit ? Bref dis
moi ce que tu préfères..

ok envoie le final, ce n'est pas si pressé.

Merci et a bientot

      Emmanuel

11

Salut,
pour essayer d'avancer vers un espace rédaction utilisant un peu les
fonctionnalités de Spip, j'ai attaqué les modifs de insere_en_table, le but
etant de faire un "edit_table" complet.
La premiere phase était de pouvoir passer un id et de recuperer le contenu
correspondant, en faisant un truc du genre :
function table_extra_get_value($nom, $field, $key, $file, $id)
{
$lWhere=$key["PRIMARY KEY"]."=".$id;
if (!($res=spip_abstract_select (array_keys($field), array($nom),
array($lWhere)))) {
  //TODO : l'id n'existe pas. pour le moment => repasser en création
  return table_extra_get($nom, $field, $key, $file);
}
$row=spip_abstract_fetch($res);
...

et en mettant $row[$k] dans les valeurs

Ben, c'est pas evident !
1) les fonctions abstract sont dans inc-calcul.
A terme, ca pourra etre interessant, mais pour le moment, pour faire juste
un select, ca fait un peu lourd, d'autant que les include_local posent
quelques problemes ...
2) l'utilisation de include_local pose un réel souci : l'appel etant fait
depuis le repertoire ecrire, tous les chemins lui sont relatifs.
Pour l'include lui meme, pas de souci, mais tous les includes du fichier en
question ne marchent evidement pas.

La soluce que j'ai trouvé pour l'instant, c'est de les avoir inclus AVANT,
j'ai fait une petite fonction à part pour ne pas me melanger les pinceaux :
function include_local_ecrire($file) {
if ($GLOBALS['included_files'][$file]) return;
include("../".$file);
$GLOBALS['included_files'][$file] = 1;
}
Du coup, au debut de insere_en_table, j'ai mis :
include_local_ecrire("inc-admin.php3");
include_ecrire ("inc_db_mysql.php3");
include_ecrire ("inc_documents.php3");
include_ecrire ("inc_barre.php3");

et j'ai repris toutes les fonctions abstract en attendant (elles sont bien
pratiques, il faudrait peut etre les mettre dans un fichier à part).

Je ne sais pas si c'est la bonne piste, mais je vois mal comment on peut
s'en tirer mieux avec ces histoires de chemins relatifs et cette approche
exploite la logique du include_ecrire et include_local.

Autre probleme potentiel levé pendant ces petits bidouillages : des
fonctions ayant le meme nom ...
Je suis tombé sur generer_url_article mais il y en a sans doute d'autres

voila, c'etait juste pour faire avancer le chimilimilichimilimili ... enfin
pour en causer quoi !

@++

12

Je regarde un peu mon code (un peu commenté malgré tout) et voila en
vrac :

Commandes invalides en SQL ANSI
- Utilisation des doubles quotes pour les chaines de caractères
- INSERT IGNORE
- REPLACE
- INSERT "MULTIPLES" avec une succession de VALUES (install)
- LIMIT x,y au lieu LIMIT x OFFSET y
- FIELD / REGEXP (spécifique à chaque DB)
- Utilisation de dates à '00-00-0000'

Au niveau du code SPIP en lui meme :
- Les champs définis comme NOT NULL ne sont pas renseignés dans les
requêtes d'INSERT (MySQL ne bronche pas !)
- La façon de récupérer l'ID d'une nouvelle entité est spécifique à
MySQL.
- Certaines suppressions se font sans tenir compte de l'intégrité
référentielle (On vire le père avant de deleter les fils ... (sic))

- SELECT * FROM .... GROUP BY nom_d'un_champ , PostgreSQL veut les
champs sélectionnés explicitement ... (je ne sais pas trop ce qu'en dit
la norme, mais les SELECT * me rendent méfiant ..)

J'espère que ça t'aidera !!

  Arnaud

13

Le 22 oct. 04, ˆ 10:19, Stephane LAURENT a Žcrit :

Salut,
pour essayer d'avancer vers un espace rŽdaction utilisant un peu les
fonctionnalitŽs de Spip, j'ai attaquŽ les modifs de insere_en_tableÅ

Ben, c'est pas evident !
1) les fonctions abstract sont dans inc-calcul.
A terme, ca pourra etre interessant, mais pour le moment, pour faire juste
un select, ca fait un peu lourd, d'autant que les include_local posent
quelques problemes ...

Tu as raison. Je viens de les extraire de inc_calcul et je les ai mises
dans un rŽpertoire de ecrire car effectivement on commence ˆ les utiliser
dans l'espace d'administration plus seulement dans les squelettes.
Il s'appelle ecrire/inc_abstract_sql.php3

2) l'utilisation de include_local pose un rŽel souci : l'appel etant fait
depuis le repertoire ecrire, tous les chemins lui sont relatifs.

Du coup, au debut de insere_en_table, j'ai mis :
include_local_ecrire("inc-admin.php3");

Je ne comprends pas pourquoi tu as besoin de ce fichier.

      Emmanuel

14

Je rajouterai aussi ceci :
les "SELECT COUNT(*) FROM .... ORDER BY machin" nécessitent un GROUP BY machin
sous postgresql

15

Tu as raison. Je viens de les extraire de inc_calcul et je les ai mises
dans un rŽpertoire de ecrire car effectivement on commence ˆ les
utiliser
dans l'espace d'administration plus seulement dans les squelettes.
Il s'appelle ecrire/inc_abstract_sql.php3

OK, merci.

Du coup, au debut de insere_en_table, j'ai mis :
include_local_ecrire("inc-admin.php3");

Je ne comprends pas pourquoi tu as besoin de ce fichier.

perso, je m'en passerai bien, mais dans inc_db_mysql, il y a ligne 81 :
include_local('inc-admin.php3');
qui plante (vu que le fameux 'inc-admin.php3' est attendu dans /ecrire), il
faut donc bien que je l'ai deja inclu.

Mais ˆ la limite, ce n'est pas ce cas particulier qui m'interesse mais
essayer d'anticiper un peu les pbs qu'on va avoir ˆ utiliser des fonctions
communes depuis / et /ecrire

sinon, avant que j'y passe le week end, personne n'avait avancŽ la contrib
dans ce sens (ajout des "update") ?

@++

16

Commandes invalides en SQL ANSI
- Utilisation des doubles quotes pour les chaines de caractères

Il me semble que tous les cas ont été évacués sur la CVS.

- INSERT IGNORE

ok

- REPLACE

là il va falloir introduire une fonction d'abstraction

- INSERT "MULTIPLES" avec une succession de VALUES (install)

tu veux dire qu'il y a seulement ceux de inc_base ?
de toutes façons la table type_document ne se justifie pas:
elle n'est utilisée qu'en lecture et nous songeons du coup à la remplacer
par le tableau PHP implicite qui la créé pour éviter le Join constant
qui en découle dans la boucle DOCUMENTS.
Ca fait donc un argument de plus.

- LIMIT x,y au lieu LIMIT x OFFSET y

ok

- FIELD / REGEXP (spécifique à chaque DB)

ok

- Utilisation de dates à '00-00-0000'

Ca c'est plus galère et ça repose le pb du format des dates.
Je trouve le format ICS le plus astucieux et le plus complet (notamment pour le fuseau horaire)
mais en attendant faut faire sans.

Au niveau du code SPIP en lui meme :
- Les champs définis comme NOT NULL ne sont pas renseignés dans les
requêtes d'INSERT (MySQL ne bronche pas !)

bigre, ça aussi faut faire une revue de détail.

- La façon de récupérer l'ID d'une nouvelle entité est spécifique à
MySQL.

oui, de nouveau il faut une fonction d'abstraction.

- Certaines suppressions se font sans tenir compte de l'intégrité
référentielle (On vire le père avant de deleter les fils ... (sic))

Là aussi, revue de détail en vue.

- SELECT * FROM .... GROUP BY nom_d'un_champ , PostgreSQL veut les
champs sélectionnés explicitement ... (je ne sais pas trop ce qu'en dit
la norme, mais les SELECT * me rendent méfiant ..)

Le compilateur de squelette est au courant, et de nouveau si on réécrit
l'espace de rédaction à coup de squelette ça nous résoudra le pb automatiquement.

J'espère que ça t'aidera !!

Beaucoup ! mille mercis! Je vais commencer par vérifier que le compilateur produit du code SQL compatible; le reste ça risque d'être pour plus tard.

      Emmanuel

17

> Commandes invalides en SQL ANSI
> - Utilisation des doubles quotes pour les chaines de caractères
Il me semble que tous les cas ont été évacués sur la CVS.

Ba pas sur mon dépôt :wink:
J'en avais une bonne dizaines qui trainaient dans les fichiers utilisés par
l'interface d'administration

> - REPLACE

là il va falloir introduire une fonction d'abstraction

En ce qui me concerne c'est déjà fait : si le driver pgsdql est utilisé, le
REPLACE est remplacé par un appel à UPDATE puis, s'il n'y pas eu de ligne
modifiée, un appel à INSERT

> - Utilisation de dates à '00-00-0000'

Ca c'est plus galère et ça repose le pb du format des dates.
Je trouve le format ICS le plus astucieux et le plus complet (notamment
pour le fuseau horaire)
mais en attendant faut faire sans.

Moi je me suis débrouillé en remplacement la date par défaut à '1900-01-01
00:00:00' qui fait très bien l'affaire :wink:

> Au niveau du code SPIP en lui meme :
> - Les champs définis comme NOT NULL ne sont pas renseignés dans les
> requêtes d'INSERT (MySQL ne bronche pas !)
bigre, ça aussi faut faire une revue de détail.

J'en ai déjà quelques uns dans un coin, le temps de finir mes modifs et
j'espère les avoirs tous....tu pourras donc voir la liste des colonnes à
modifier

> - La façon de récupérer l'ID d'une nouvelle entité est spécifique à
> MySQL.
oui, de nouveau il faut une fonction d'abstraction.

oui mais il y a un gros problème qui se pose :
mysql récupère l'id *après* l'insert tandis que postgresql génère l'id *avant*
donc pour le moment je ne sais pas trop comment faire

18

ok, de nouveau j'ai extrait les fonctions d'erreurs pour les mettre dans un fichier d'ecrire:
ecrire/inc_debug_sql.php3.

En fait, il existait dans l'ancienne version un fichier inc-debug-squel qui a été fusionné
avec inc-admin lorsqu'on a décidé de commander la visualisation des erreurs de squelette à partir des boutons d'administration. Mais dans la perspective de squelette dans l'espace d'administration il est plus logique de le resusciter en le mettant dans cet espace.

      Emmanuel

19

Tant qu'a nettoyer le SQL pour avoir une compatibilité PostGres/Mysql, n'est il pas possible de passer via adodb ( http://adodb.sourceforge.net/ ) qui permettera d'utiliser sqlite et autres bases plus ou moins exotique.

M.

20

Mathieu Lecarme wrote:

Tant qu'a nettoyer le SQL pour avoir une compatibilité PostGres/Mysql,
n'est il pas possible de passer via adodb (
http://adodb.sourceforge.net/ ) qui permettera d'utiliser sqlite et
autres bases plus ou moins exotique.

Je soutiens l'idée :wink: