RE: [spip-dev] SPIP & PostgreSQL

Dev
1

Le plus long a été de modifier et vérifier le code de création des
tables et d’installation. Ce n’est pas compliqué, c’est méthodique.

Moi aussi je suis le portage, mais je suis un peu plus à la bourre que
toi. Mais les remarques sont à peu près les mêmes.

Je suis sur un spip 1.7 et un postgreSQL 7.4.1

Plus quelques bugs découvert dans le code.

Le site est visible sur http://rilk.com/spip17/pg/
Démonstration demo:123456

J'aimerais savoir si vous accepteriez en retour de ce test
1) des commentaires ?
2) des patches ?
Les patches que je propose rendent le SQL plus standard, i.e je compte
supprimé:
- SELECT * FROM ... GROUP BY
- valeur escaped avec des " (remplacer par des ' )
- et autres détails.
Acceptez vous de supprimer l'usage de REPLACE dans le code ? et des
INSERT multiple ?

Techniquement, j'ai surtout modifié ecrire/install.php3,

Moi j'ai fait un script SQL à coté pour créer les bases from scratch.
Rajouter l'intégrité référentielle etc ....

ecrire/inc_db_mysql.php3.
Je devrais d'ailleurs renommer ce dernier fichier en
ecrire/inc_db_pgsql.php3 mais je ne sais pas encore comment faire pour
proposer en choix le type de BD lors de l'install. **

J'avais pensé faire un lien symbolique lors de l'installation avec
inc_db qui pointe soit sur inc_db_pgsql.php3 ou sur la version Mysql.
Bon pour les windowsiens ... ca risque de coincer !

J'ai modifié traite_query() qui me convertit les requetes MySQL en
PgSQL. Pas simple (surtout REPLACE), mais ca marche.

Oui c'est pas super logique, j'ai tenté un insert et si ça rate, je fais
fais un delete avant ... c'est pas top :frowning: mais bon .. REPLACE n'est pas
un ordre SQL standard.

Je n'ai pas encore trouvé de solution satisfaisante pour les dates
inexistantes 0000-00-00 et pour les nom de colonnes qui commence par
des chiffres (0minirezo, 1comite, 6forum).

J'avais pensé pour ma part, utiliser des triggers sur insert et update
pour altérer les dates invalides. Et inverser les chiffres dans les noms
de colonnes ( ex: 0minirezo devient minirezo0)

J'ai une question un peu connexe, l'équipe SPIP désire t'elle se lancer
dans la voie de la compatibilité PostgreSQL (ou autre) ? et la maintenir
au fil des versions ? Ou cela restera des patches valables version par
version ?

Cordialement,
Jean-Gérard Pailloncy

Cordialement,
  Arnaud Brugnon

2

Bravo les gars pour vos efforts… Je vous encourage à continuer et j’espère que l’équipe de dev de spip
intégrera et maintiendra la possibilité d’utiliser d’autres bases que mysql et en particulier postgre. Qu’ils sachent
qu’il y a une demande dans ce sens.
F.

Arnaud Brugnon wrote:

3

>J'aimerais savoir si vous accepteriez en retour de ce test
>1) des commentaires ?
>2) des patches ?

Euh, depuis quand on refuserait commentaires et patches ? Evidemment ! :slight_smile:

>Les patches que je propose rendent le SQL plus standard, i.e je compte
>supprimé:
>- SELECT * FROM ... GROUP BY
>- valeur escaped avec des " (remplacer par des ' )
>- et autres détails.
>Acceptez vous de supprimer l'usage de REPLACE dans le code ? et des
>INSERT multiple ?

Ca peut se faire soit dans le code, soit dans ecrire/inc_db_pgsql.php3 ; il
faut voir ce qui est le plus souple et nous laisse le plus de liberté pour
coder.

>Techniquement, j'ai surtout modifié ecrire/install.php3,
Moi j'ai fait un script SQL à coté pour créer les bases from scratch.
Rajouter l'intégrité référentielle etc ....

Je dirais que l'installation n'est pas prioritaire, et il faudra qu'on fasse
très attention aux upgrades ; pour ça il faudra pas mal de vigilance.

>Je devrais d'ailleurs renommer ce dernier fichier en
>ecrire/inc_db_pgsql.php3 mais je ne sais pas encore comment faire pour
>proposer en choix le type de BD lors de l'install. **

A priori il faudrait ajouter un sélecteur (bouton radio) en bas de la page
de connexion à la base. Sauf si pgSQL nécessite des "données de connexion"
d'un format différent de host/user/passwd

J'avais pensé faire un lien symbolique lors de l'installation avec
inc_db qui pointe soit sur inc_db_pgsql.php3 ou sur la version Mysql.
Bon pour les windowsiens ... ca risque de coincer !

Non, mauvaise méthode :slight_smile:

>J'ai modifié traite_query() qui me convertit les requetes MySQL en
>PgSQL. Pas simple (surtout REPLACE), mais ca marche.

Ca c'est le plus intéressant, car ça nous laisse plus libre pour la suite.
Pour les aspects techniques précis (REPLACE etc), si vraiment ça coince, ou
si c'est du code MySQL qu'on utilise très peu, on peut changer dans le code
de SPIP. Mais l'idéal, pour moi, c'est de mettre toute l'"intellignecce"
possible dans la procédure de conversion.

>Je n'ai pas encore trouvé de solution satisfaisante pour les dates
>inexistantes 0000-00-00 et pour les nom de colonnes qui commence par
>des chiffres (0minirezo, 1comite, 6forum).

J'avais pensé pour ma part, utiliser des triggers sur insert et update
pour altérer les dates invalides. Et inverser les chiffres dans les noms
de colonnes ( ex: 0minirezo devient minirezo0)

Ca ça peut se changer, en revanche, dans le code de SPIP. Il faut faire une
liste des choses à modifier

J'ai une question un peu connexe, l'équipe SPIP désire t'elle se lancer
dans la voie de la compatibilité PostgreSQL (ou autre) ? et la maintenir
au fil des versions ? Ou cela restera des patches valables version par
version ?

Oui, pourquoi pas, si c'est fait de manière simple et pratique, c'est une
bonne idée.

-- Fil

4

> >Je devrais d'ailleurs renommer ce dernier fichier en
> >ecrire/inc_db_pgsql.php3 mais je ne sais pas encore comment faire pour
> >proposer en choix le type de BD lors de l'install. **

Moi j'ai laissé tombé l'idée d'une procédure automatisée. Surtout vu la
population qui utilise postgreSQL. C'est pas vraiment un SGBD 'grand
public' donc les gens sont capables de se creer un user, une base et de
passer un script .. surtout si c'est décrit dans un doc INSTALL.pgsql
par exemple.

A priori il faudrait ajouter un sélecteur (bouton radio) en bas de la page
de connexion à la base. Sauf si pgSQL nécessite des "données de connexion"
d'un format différent de host/user/passwd

Les informations de connexion pour postgres sont les mêmes que MySQL. On
pourrait s'en sortir élégament en ajoutant un paramètre
db_type=(mysql|pgsql) dans le inc-connect.php3 et faire un include
inc_db_$dbtype dans le code.

> >J'ai modifié traite_query() qui me convertit les requetes MySQL en
> >PgSQL. Pas simple (surtout REPLACE), mais ca marche.

Ca c'est le plus intéressant, car ça nous laisse plus libre pour la suite.
Pour les aspects techniques précis (REPLACE etc), si vraiment ça coince, ou
si c'est du code MySQL qu'on utilise très peu, on peut changer dans le code
de SPIP. Mais l'idéal, pour moi, c'est de mettre toute l'"intellignecce"
possible dans la procédure de conversion.

A priori ça marche pas mal pour les cas simples et les fonctions
inexistantes ou ayant une syntaxe différents
- Date_add, date_sub,
- replace,
- limit ,
- hex
- dates en '0000-00-00'
- INTERVAL
- remplacement des " par des '
- Suppression des Order by sur des count(*) :wink:
- remplacement à la volée des '0minirezo' en 'minirezo0' (mais ça ne
doit pas marcher tres bien ...)

>
> J'avais pensé pour ma part, utiliser des triggers sur insert et update
> pour altérer les dates invalides. Et inverser les chiffres dans les noms
> de colonnes ( ex: 0minirezo devient minirezo0)

Ca ça peut se changer, en revanche, dans le code de SPIP. Il faut faire une
liste des choses à modifier

J'ai avancé sur l'insertion de différents objets (article, auteur,
breves, rubrique) ... et là j'ai du modifier le code de SPIP car c'est
impossible sous postgres d'insérer un enregistrement alors que ses
champs sont marqués NOT NULL .. alors 2 solutions :
- Assouplir les contraintes dans la définition de la base
- modifier le code PHP pour insérer les informations a la bonne place
D'autre part, la fonction mysql_insert_id n'existe pas. J'ai codé le
remplacement en passant en paramétre le nom de la séquence qui gérer la
clé primaire (reste a définir des noms explicites pour ça puisse tourner
sur d'autres bases si besoin était). Les modifs

Maintenant je m'attaque à l'utilisation du site et je rencontre les
mêmes problèmes que Jean-Gerard. Des requêtes carrément refusées par
postgresql.
Principalement des "SELECT * .... GROUP BY ... ORDER BY " et là ...
franchement, a part trifouiller franchement dans le sode SPIP .. je ne
vois pas d'astuces à mettre dans inc_db_pgsql !!! Et je maudis gentiment
la syntaxe permissive (et de fainéants !!) de MySQL.

Je pense que la modification sera compatible avec MySQL étes vous OK
pour intégrer les patchs et à qui je dois les envoyer ?

> J'ai une question un peu connexe, l'équipe SPIP désire t'elle se lancer
> dans la voie de la compatibilité PostgreSQL (ou autre) ? et la maintenir
> au fil des versions ? Ou cela restera des patches valables version par
> version ?

Oui, pourquoi pas, si c'est fait de manière simple et pratique, c'est une
bonne idée.

OK j'avance la dessus.

5

Je pense que la modification sera compatible avec MySQL étes vous OK
pour intégrer les patchs et à qui je dois les envoyer ?

Tu les envoies ici, et après on verra bien si on est OK pour les intégrer :slight_smile:
Sur le principe, oui, si c'est suffisamment simple et que ça ne nous bride
pas trop dans l'écriture des requêtes.

Quand tu parles de "syntaxe MySQL permissive", que veux-tu dire ? GROUP
BY... ORDER BY... c'est bien pratique, non ? En quoi est-ce supérieur de se
l'interdire ?

-- Fil

6

> Je pense que la modification sera compatible avec MySQL étes vous OK
> pour intégrer les patchs et à qui je dois les envoyer ?

Tu les envoies ici, et après on verra bien si on est OK pour les intégrer :slight_smile:
Sur le principe, oui, si c'est suffisamment simple et que ça ne nous bride
pas trop dans l'écriture des requêtes.

OK, normalement ça ne devrait pas brider grand chose. C'est juste des
réécritures de requêtes. je ne vais pas m'amuser à utiliser des choses
incompatibles avec MySQL (subselect etc ..)

Quand tu parles de "syntaxe MySQL permissive", que veux-tu dire ? GROUP
BY... ORDER BY... c'est bien pratique, non ? En quoi est-ce supérieur de se
l'interdire

Je ne souhaitais pas déclencher un troll PostgreSQL contre MySQL ! ;-))

En SQL les champs qui figurent dans les clauses d'aggrégation (Group by)
ou de tri doivent etre explicitement dans le select. Si tu le tentes
avec un quelconque autre moteur SGBD (Oracle par ex) tu te fais jeter
car ce n'est pas standard.

Une autre raison, qui est plutot une bonne pratique, c'est de ne jamais
utiliser * dans un SELECT. Autant préciser explicitement les champs que
l'on souhaite utiliser dans le traitement. C'est + long et pénible mais
c'est plus clair.

Et d'autre part MySQL autorise les création des Colonnes dans les tables
avec la contraintes NOT NULL ... mais ne vérifie pas au moment de
l'insertion (c'est pas cool car on "croit" qu'on est blindé alors que
non). en tout cas sur Mysql 3.23 livré avec la fedora.

Je pense qu'on va avoir d'autres surprises avec l'intégrité
référentielle de postgres mais chaque chose en son temps.

A+

  Arnaud

7

Salut,

Je viens de me replonger dans SPIP-Pg.

Je re-écris les requêtes dynamiquement dans traite_sql.
Sauf quand je peux pas (GROUP BY ;-/)

Mais il y a plein de fonction MySql qui n'existe pas en PgSql.
On peut en fait facilement créer certaines fonctions qui émule très bien MySql

J'ai donc créer:
DAYOFMONTH
HEX
MONTH
RAND
TO_DAYS
UNIX_TIMESTAMP
YEAR
least

C'est propre car je n'ai pas besoin de parser la requête pour voir si je modifie on non quelque chose, Pg se débrouille très bien avec.

A+
Jean-Gérard

8

Bonjour,

Sur Spip 1.7, easyphp 1.7, win 98SE, Charset UTF8, options : moteur de recherche, référé, et date de publication antérieure, mises à 'on'

Bug entraînant le non fonctionnement de l'indexation ... vient du fait que les métas ne sont pas gardés en mémoire, le fichier inc_meta_cache n'est pas créé dans ecrire/data

du coup la fonction recalcul des rubriques, dans le cas de la publication post daté, dans inc_public_global, est lancée à chaque fois, les actions qui suivent sont alors systématiquement ignorées.

--> if ((time()-lire_meta('calcul_rubriques') > 3600) AND timeout('calcul_rubriques')) {

lire_meta('calcul_rubriques') ne vaut rien donc if vrai à chaque fois

dans inc_meta, le code problématique :

// $fichier_meta_cache = ($flag_ecrire ? '' : 'ecrire/') . 'data/inc_meta_cache.php3';
// $f = @fopen($fichier_meta_cache.'.'.@getmypid(), "wb");
// if ($f) {
// @fputs($f, $s);
// @fclose($f);
// @unlink($fichier_meta_cache);
// @rename($fichier_meta_cache.'.'.@getmypid(), $fichier_meta_cache);
// } else {

il me renvoie un warning, quand je vire les @ :

Warning : rename(ecrire/data/inc_meta_cache.php3.,ecrire/data/inc_meta_cache.php3): No such file or directory in c:\program files\easyphp\www\spip-1.7\ecrire\inc_meta.php3 on line 81

en remplaçant ce code par celui de spip 1.6 :

// $f = @fopen(($flag_ecrire ? "" : "ecrire/") . "data/inc_meta_cache.php3", "wb");
// if ($f) {
// fputs($f, $s);
// fclose($f);
// } else {

tout rentre dans l'ordre et j'obtiens de nouveau l'indexation

9

Source du problème : en fait getmypid() ne renvoit rien (je ne connais pas assez le php pour dire pourquoi), tout marche quand on remplace cette fonction par un numéro fixe, mais on risque alors des collisions dans les mises a jour de inc_meta_cache.

  dans inc_meta, le code problématique :

  // $fichier_meta_cache = ($flag_ecrire ? '' : 'ecrire/') .
  'data/inc_meta_cache.php3';
  // $f = @fopen($fichier_meta_cache.'.'.@getmypid(), "wb");
  // if ($f) {
  // @fputs($f, $s);
  // @fclose($f);
  // @unlink($fichier_meta_cache);
  // @rename($fichier_meta_cache.'.'.@getmypid(),
  $fichier_meta_cache);
  // } else {

Je pense que ce problème concerne plusieurs personnes travaillant également sous easyphp 1.7 et windows, d'après certains messages de la listes

Romain

10

Pailloncy Jean-Gérard a écrit :

Salut,

Je viens de me replonger dans SPIP-Pg.

Je re-écris les requêtes dynamiquement dans traite_sql.
Sauf quand je peux pas (GROUP BY ;-/)

Mais il y a plein de fonction MySql qui n'existe pas en PgSql.
On peut en fait facilement créer certaines fonctions qui émule très bien MySql

J'ai donc créer:
DAYOFMONTH
HEX
MONTH
RAND
TO_DAYS
UNIX_TIMESTAMP
YEAR
least

C'est propre car je n'ai pas besoin de parser la requête pour voir si je modifie on non quelque chose, Pg se débrouille très bien avec.

A+
Jean-Gérard

Et dans Pear DB ils font comment?

11

PEAR::DB sert à l'abstraction vis à vis de la base de données afin
d'éviter de hardcoder dans PHP directement les instructions pour une
base spécifique (ex: mysql_query ou pg_query). Mais il ne joue pas sur
la syntaxe du SQL qui est exécuté.

12

Je re-écris les requêtes dynamiquement dans traite_sql.
Sauf quand je peux pas (GROUP BY ;-/)

Je crois qu'on va être obligé de se les modifier à la main ces requêtes
!!! :-((((

J'ai déjà tout fait.

Cordialement,
Jean-Gérard Pailloncy

13

Pailloncy Jean-Gérard a écrit :

Je re-écris les requêtes dynamiquement dans traite_sql.
Sauf quand je peux pas (GROUP BY ;-/)

Je crois qu'on va être obligé de se les modifier à la main ces requêtes
!!! :-((((

J'ai déjà tout fait.

Est ce que ce portage ne nécessiterais pas un CVS et éventuellement une liste de discussion dédié pour coordonner les efforts?

14

Julien Duponchelle a écrit :

Pailloncy Jean-Gérard a écrit :

Je re-écris les requêtes dynamiquement dans traite_sql.
Sauf quand je peux pas (GROUP BY ;-/)

Je crois qu'on va être obligé de se les modifier à la main ces requêtes
!!! :-((((

J'ai déjà tout fait.

Est ce que ce portage ne nécessiterais pas un CVS et éventuellement une liste de discussion dédié pour coordonner les efforts?

un wiki ? : http://wiki.rezo.net :slight_smile:

15

Cool !!!! je suis client !! ;-))))
Et tu as envoyé les patchs sur spip-dev ?
Tu as fait les diffs sur la version 1.7 ?

Ben, non.

J'ai fait ça Dimanche et Lundi dernier.
J'ai actuellement un problème de connexion ssh avec mon serveur alors je ne peux pas récupérer les fichiers.
C'est idiot, je sais.

Sinon, on peut tester la configuration.
SPIP 1.7-Pg fonctionne sur http://rilk.com/spip17/pg/
J'ai créé un compte de test demo:123456

C'est presque complet, il me manque juste de rajouter dans inc_base.php3 la création des fonctions. Sinon les tables, index etc tout marche.
Même le choix du port pour la base de données.

Cordialement,
Jean-Gérard Pailloncy

16

Je pense que ce projet aurait tout à fait sa place dans une sorte de
SPIP expérimental, avec deux trois autres trucs de la todo list
impossibles à intégrer dans le spip actuel (sans tout casser)... non ?

17

Source du problème : en fait getmypid() ne renvoit rien (je ne connais
pas assez le php pour dire pourquoi), tout marche quand on remplace
cette fonction par un numéro fixe, mais on risque alors des collisions
dans les mises a jour de inc_meta_cache.

Ce n'est pas très grave ; par contre je ne comprends pas en quoi ça peut
être bloquant : si getmypid() est vide, le fichier ouvert est
$fichier_meta_cache.'.', qui est ensuite renommé en $fichier_meta_cache
Est-ce que c'est le '.' final qui fait planter le système de fichiers ?

-- Fil

18

D'un autre côté, sous postgreSQL, pour créer un utilisateur tu fais comme avec
n'importe quel autre SGBD (donc forcément je n'inclue pas MySQL), tu utilises
une instruction SQL qui a été normalisée il y a 12 ans : CREATE USER.

Donc en fait, t'as pas besoin de lire la doc INSTALL.pgsql.

Le logiciel libre se targue d'utiliser des normes publiques et ouvertes. À ce
titre je me demande ce que vient foutre MySQL dans la catégorie "Logiciels
libres".

- --
Hervé LEFEBVRE http://www.linux-public.org
aegir@free.fr

19

@ Fil <fil@rezo.net> :

> Source du problème : en fait getmypid() ne renvoit rien (je ne connais
> pas assez le php pour dire pourquoi), tout marche quand on remplace
> cette fonction par un numéro fixe, mais on risque alors des collisions
> dans les mises a jour de inc_meta_cache.

Ce n'est pas très grave ; par contre je ne comprends pas en quoi ça peut
être bloquant : si getmypid() est vide, le fichier ouvert est
$fichier_meta_cache.'.', qui est ensuite renommé en $fichier_meta_cache
Est-ce que c'est le '.' final qui fait planter le système de fichiers ?

Sans certitudes, je tente une correction.

-- Fil

20

ATT02747.txt (889 Bytes)