[spip-dev] SPIP & PEAR ...

Dev
1

Bonjour,

comme je vous l'ai déjà signalé, nous travaillons actuellement sur une
modification de SPIP pour qu'il devienne indépendant de la base de
données utilisée.

Pour cela, nous allons utiliser PEAR DB (http://pear.php.net) pour
tous les accès, mais cela ne suffit pas, il faut aussi transformer les
requêtes pour qu'elles soient compatibles avec les SGBD standards.

Nous prévoyons de rendre SPIP compatible au moins avec les SGBD
suivants :
- MySQL 3.23.x
- PostgreSQL 6.5.x
- Oracle 8.x
- SQL Server 7.x

Une base de travail est fournie par MySQL :
http://www.mysql.com/information/crash-me.php

Pour cela, nous devons tout d'abord modifier le schéma de la base pour
qu'il n'utilise que des types de données standards, selon la norme
ANSI SQL92 supportée par ces SGBD. C'est aussi l'occasion de
rationnaliser un peu les types de données utilisés jusqu'à présent un
peu à tord et à travers.

Quelques questions en vrac pour commencer cette réflexion :
- pourquoi le champ 'fichier' de la table 'spip_forum_cache', par
  exemple, est-il en format BINARY ?
- pourquoi utiliser des BIGINT plutôt que de "simples" INT pour les id
  d'article ?
- pourquoi utiliser parfois un TIMESTAMP et parfois un DATETIME ?
- pourquoi mélanger les types BLOB, LONGBLOB, MEDIUMTEXT, TEXT, etc au
  lieu d'utiliser uniquement des TEXT et VARCHAR ?

Par exemple, il faudrait faire de meilleurs choix entre les types
LONGBLOB, TEXT, TINYTEXT, MEDIUMTEXT et VARCHAR ...

De même, il faudrait rationnaliser les TIMESTAMP et DATETIME,
éventuellement en les remplaçant par des INT avec un "vrai" timestamp
géré en PHP.

Nous préparons actuellement un tableau Excel permettant de voir
quelles fonctionnalitées et quels types de données sont standards et
pourraient être utilisés. Si quelqu'un veut y jeter un oeil, je peux
lui envoyer.

Cette grosse réflexion (que nous devons mener très très rapidement)
nous amènera à déterminer un nouveau modèle de données et les
modifications à effectuer en conséquence sur le code de SPIP.

Merci d'avance pour vos idées que j'espère nombreuses.

-Nicolas

2

Salut,
bon ma question sera peut être bête mais tant pis au moins je serai fixé !
Le fait d'utiliser PEAR ne demande-t-il pas que le module PEAR soir
installer sur le serveur qui héberge le site ?! Car les serveurs mutualisés
d'AMEN par ex n'ont pas de module PEAR d'installé. Voilà une copie de la
réponse du service technique : "le module PEAR n'est pas installé sur nos
serveurs mutualisés et nous ne pouvons modifier la configuration de ses dits
serveurs, désolé".

J'espère que c'est bon tout de même, car sinon SPIP deviendrait incompatible
avec AMEN et sans doute d'autres non ? Ce qui représente bcp de gens !
Enfin je mélange peut être tout !

Merci de m'éclairer,

3

Hello,

pear etant juste une collection de script php il est tout a fait
possible de la copier dans le repertoire de spip et de l'utiliser
comme ca
pour une activation globale pear ne demande pas vraiment d'installation il suffit de
copier son arborescence dans le chemin des include standard et c bon

4

Salut,

De retour...

- pourquoi le champ 'fichier' de la table 'spip_forum_cache', par
  exemple, est-il en format BINARY ?

Parce qu'un nom de fichier, c'est sensible à la casse, et qu'on
fait des WHERE fichier = "...". En règle générale, je me méfie
des types "case-insensitive", dont le comportement chiant et
imprévisible varie avec la locale et autres bidules.

- pourquoi utiliser des BIGINT plutôt que de "simples" INT pour les id
  d'article ?

Historique. Il faudrait passer en INT (déjà fait pour spip_index_*,
afin de gagner de la place).

- pourquoi utiliser parfois un TIMESTAMP et parfois un DATETIME ?

- TIMESTAMP : mis à jour automatiquement par MySQL, utilisé pour la
gestion de versions (restauration base, puis éventuellement synchro
sites, etc)

- DATETIME : date entrée par l'utilisateur, spectre de valeurs assez
large, possibilité de valeurs "imprécises" (jour = 00 par exemple)

- pourquoi mélanger les types BLOB, LONGBLOB, MEDIUMTEXT, TEXT, etc au
  lieu d'utiliser uniquement des TEXT et VARCHAR ?

Incohérences historiques. Enfin, rien de mal. Attention quand même
à choisir un type permettant plus de 65535 caractères, notamment pour
le corps de texte des articles.

éventuellement en les remplaçant par des INT avec un "vrai" timestamp
géré en PHP.

Non, spectre de valeurs pas assez large à mon avis.

a+

5

Salut,
super cette précision. Bon je me permets de poser une ou deux dernières
questions en espérant que Marc et deux secondes à perdre à faire du
baby-sitter php pour moi :wink:
Qu'entends tu copier son arborescence dans le chemin des include standard
pour une activation globale. Je t'explique, j'ai SPIP installer à la racine
du site qui aura besoin de PEAR et j'ai un répertoire horde pour IMP qui
aurait besoin de PEAR également. Puis-je utilisé le même pear pour les deux
(c'est ce que tu entendrais par activation globale, non ?!). Si pour horde
tu ne sais pas peux tu me détailler au moins où il copier l'arborescence de
pear pour que SPIP marche en considérant que ce dernier est toujours à la
racine du site.

Merci d'avance pour ton aide, je suis sûr que ce sera très utile à d'autres
que moi qd SPIP aura besoin de PEAR :wink:

6

Hello,

precisions les infos qui suivent sont plus globalement pour unix mais
si vous avez installer php4 pour windows vous pourrez trouver a peu de
chose pres la meme chose (dans c:\php il y a un rep pear qui est
depuis la version 4.xx dans le chemin standard des include de php)
pear est compose d'une arborescence contenant :
PEAR.php
DB.php
System.php
......
DB/*
Date/*
Mail/*
......

il y en a trop pour tous les mettre.

ces fichiers et repertoires sur unix sont generalement dans

/chemin_d_install_d_apache/lib/php

ce chemin doit normalement ce retrouver dans le fichier php.ini au
niveau suivant(si une installation (unix) a ete faite a partir des
sources et que a la compilation il n'a pas ete specifier de desactiver
pear il est installer comme il se doit) :

;;;;;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"
;include_path = ".:/chemin_d_install_d_apache/lib/php"
;
; Windows: "\path1;\path2"
;include_path = ".;c:\php\includes"

et oui l'interet de ce type d'installation est justement que du coup
pear devient accessible par n'importe quel script php.

oui je connais horde/imp et pour lui il te faut de preference une
install de type globale sinon attention la galere il te faudrait soit
copier les fichier pear necessaires dans tous les reps ou presque de horde/imp
car horde/imp en fait un usage intensif, soit modifier tous les
require de pear dans les sources et la ca peut devenir tres long

pour ce qui est de la copie des fichiers pear necessaire pour spip ce
serait plus simple car il n'y a que 2 reps et seul la partie PEAR::DB
serait utiliser (pour horde/imp je ne sais pas s'ils utilisent
d'autres librairies de PEAR en plus de PEAR::DB)

donc pour spip il suffirait de copier :
PEAR.php
DB.php
DB/*

c bien entendu le strict minimum pour la classe d'abstraction des base
de donnees. ces fichiers/reps seraient a mettre directement dans la racine et
dans ecrire/

dans le rep DB/ il y a un fichier par base de donnees il y a juste
besoin de celui ou ceux qui interesse.
PEAR par defaut les installe tous.

pour info pear evolue beaucoup plus vite que les versions php ne
sortent et c volontaire. donc pour mettre a jour pear il suffit sans
aucune recompilation ou modif de la config d'installer et d'ecraser
les anciens fichier php de pear par les nouveaux pour mettre a jour
pear c simple ;-))

precisions ce n'est pas parce qu'on utilise une classe d'abstraction
que php ne doit pas etre compile avec le support des bases de donnees
voulus. je m'explique si php n'a pas ete compiler avec par ex le
support de postgreSQL la classe d'absctraction ne pourras pas
fonctionner pour postgreSQL.

quand on download php il existe un rep pear dans l'archive qui
contient donc toutes les lib pear actuelles.

pour ceux que ca interresse j'ai une archive ne contenant que pear
extrait de la version 4.2.1 de php. l'archive ne fait que 300ko.

7

Bonjour,

Le fait d'utiliser PEAR ne demande-t-il pas que le module PEAR soir
installer sur le serveur qui héberge le site ?!

Si ton hébergeur met à ta disposition un (ou plusieur) répertoire
présent dans l'include_path, alors tu peux y placer l'arborescence de
classes de PEAR.

Je le fais notamment sur Online et Nexen.

-Nicolas

8

Bonjour,

De retour...

Welcome back ! Bien reposé ? :slight_smile:

pourquoi le champ 'fichier' de la table 'spip_forum_cache', par
exemple, est-il en format BINARY ?

Parce qu'un nom de fichier, c'est sensible à la casse

OK, alors justement, étant donné que SPIP doit fonctionner sur tout
système, pourquoi ne pas générer que des noms de fichiers en
minuscules ?

En règle générale, je me méfie des types "case-insensitive", dont le
comportement chiant et imprévisible varie avec la locale et autres
bidules.

En effet, bonne précaution.

pourquoi utiliser des BIGINT plutôt que de "simples" INT pour les
id d'article ?

Historique. Il faudrait passer en INT (déjà fait pour spip_index_*,
afin de gagner de la place).

OK. Pas trop dur à priori, juste le schéma de base à changer, le code
pouvant rester le même.

pourquoi utiliser parfois un TIMESTAMP et parfois un DATETIME ?

TIMESTAMP : mis à jour automatiquement par MySQL, utilisé pour la
gestion de versions (restauration base, puis éventuellement synchro
sites, etc)

OK, donc c'est facilement remplaçable par un timestamp mis en PHP dans
la requête.

DATETIME : date entrée par l'utilisateur, spectre de valeurs assez
large, possibilité de valeurs "imprécises" (jour = 00 par exemple)

OK, donc c'est plus chaud, on ne peut pas remplacer ça par un "vrai"
timestamp unix-like.

Est-ce que les champs de type DATE des SGBD visés acceptent ce genre
de date imprécise ???

pourquoi mélanger les types BLOB, LONGBLOB, MEDIUMTEXT, TEXT, etc
au lieu d'utiliser uniquement des TEXT et VARCHAR ?

Incohérences historiques.

OK, ménage de printemps en vue ... :wink:

Attention quand même à choisir un type permettant plus de 65535
caractères, notamment pour le corps de texte des articles.

A priori, un champ TEXT générique devrait suffire pour le descriptif,
le chapo, et le texte des articles, et des VARCHAR pour tout le reste.

Par contre, pas trouvé le type TEXT sur Oracle, bizarre ...

éventuellement en les remplaçant par des INT avec un "vrai"
timestamp géré en PHP.

Non, spectre de valeurs pas assez large à mon avis.

OK.

-Nicolas

9

> Parce qu'un nom de fichier, c'est sensible à la casse
OK, alors justement, étant donné que SPIP doit fonctionner sur tout
système, pourquoi ne pas générer que des noms de fichiers en
minuscules ?

??

Java et C sont aussi sensibles à la casse. Pourquoi ne pas non plus
utiliser de nom de varibales/fonctions uniquement en minuscules ?

Parce que c'est plus clair en min/maj

> Incohérences historiques.
OK, ménage de printemps en vue ... :wink:

Peut être stabiliser la 1.4 avant, pour ne pas refaire l'erreur de
l'interface (ie. introduction de kilos de bugs avant la sortie d'une
stable) ?

10

oracle ne supporte malheureusement pas le type text
il supporte uniquement un type long par table et de plus ce type
long ne sert qu'a stocke (a verifier) on ne peut pas faire de like
dedans.

Oracle n'est donc pas du tout adapté au type d'appli qu'est SPIP,
c'est bien étrange vu l'orientation Web que ça a pris ces dernières
années... :frowning:

Une solution universelle serait de stocker le texte de l'article non
pas dans la base mais dans un fichier texte, mais on perd beaucoup en
simpliciter de dev ...

-Nicolas

11

Et en gestion des accès et en sécurité...
Mieux vaut stocker dans la base, c'est plus cohérent et plus logique.
Tant pis pour les SGBD de merde qui sont chers et peu maniables :wink:

12

Et en gestion des accès et en sécurité...

C'est ce dont je parlais, oui ... :wink:

Mieux vaut stocker dans la base, c'est plus cohérent et plus
logique.

"Plus cohérent et plus logique", je n'en suis pas sûr, mais bon ...

Tant pis pour les SGBD de merde qui sont chers et peu maniables :wink:

Mais qui sont souvent déjà présents dans des entreprises où on n'a pas
le droit de mettre du MySQL ...

-Nicolas

13

Bonsoir,

pourquoi ne pas générer que des noms de fichiers en minuscules ?

Mmmh, parce que les fichiers du cache sont générés à partir des
squelettes, et que si le webmestre a décidé d'avoir deux squelettes
différents, l'un nommé Article.html, l'autre article.html, SPIP doit
suivre sans trébucher.

Bonne réponse pour un système qui sait faire cette distinction, comme
les Unices et les Doz récents, mais étant donné qu'il y a encore des
systèmes ignares en la matière, je pense que c'est rendre un mauvais
services aux utilisateurs.

SPIP ne peut pas empêcher les utilisateurs de créer un squelette
ArtICle.HTML s'il le souhaite, mais il devrait en déduire un cache en
minuscules. Il suffit que ce soit documenté, et ça doit de toute façon
correspondre à 100% des cas d'utilisation.

TIMESTAMP : mis à jour automatiquement par MySQL, utilisé pour la
gestion de versions (restauration base, puis éventuellement
synchro sites, etc)

OK, donc c'est facilement remplaçable par un timestamp mis en PHP
dans la requête.

"facilement", heu, pas sûr. L'avantage du TIMESTAMP, c'est justement
que c'est automatique. Pour l'émuler à la main, il faut bien penser
à changer _toutes_ les requêtes... C'est casse-cou.

En effet, il faut changer toutes les requête INSERT et UPDATE sur les
tables ayant des champs TIMESTAMP. Assez facile à trouver, voire à
faire en automatique.

De toute façon, il va falloir changer pas mal de requête si tout ce
qui me semble souhaitable pour SPIP est appliqué ... :wink:

Est-ce que les champs de type DATE des SGBD visés acceptent ce
genre de date imprécise ???

Je n'en sais rien.... :wink:

Quelqu'un saurait répondre ?

Si ce n'est pas le cas, il va falloir diviser les dates en trois
champs, et là ça commencerait à devenir pénible. Pour les calculs
d'age, il faut de toute façon modifier ce qui est fait actuellement
avec des fonctions spécifiques MySQL, mais ça va se compliquer si on
ne peut pas utiliser un champ unique.

Par contre, pas trouvé le type TEXT sur Oracle, bizarre ...

BLOB sûrement, non ?

Apparemment c'est ça, oui, j'ai eu la même réponse d'un pote qui a
passé du temps chez Oracle.

-Nicolas

14

Ben.. effectivmeent un BLOB peut rendre les même services q'un TEXT, si
ce n'esst qu'on peut trouver un BLOB partout, sur toutes les BDD (dont
oracle), que le blob n'est pas limité aux caractères, prend donc plus de
place, et est forcément moins optimisé que du varchar, puisque les
enregistrement sont (du coup) de taille variable (donc -> fragmentation)

âis le pb est le même avec TEXT, sauf que ça prend mojns de place q'un
blob, et que ça ne se trouve pas sur oracle.

La solution serait sans doute... j'en sais rien, en fait, mais c'est
miuex d'utiliser des champs de taille fixe dans tous les cas.

15

Salut,
j'ai trouvé une solution pour tous ceux qui sont sur des serveurs mutualisés
sur lesquels PHP a été installé avec PEAR désactivé.

J'ai copier le contenu du dossier pear de php dans un dossier (nommons le
pear également...) dans le répertoire web de mon serveur. Puis à la racine
de mon site dans le fichier .htacess j'ai ajouté la ligne suivante :

php_value include_path ".:/home/sites/site114/web/pear"

Ca marche :-)))))))))))))

Magnifique je vais pouvoir accueillir les futurs modifs de SPIP et installer
HORDE sur mon serveur mutualisé.

En espérant que cela puisse aider des personnes !