[spip-dev] SPIP multi bases ...

Nicolas_Hoizey1 · Novembre 5, 2002, 10:32

Bonjour,

je reviens donc à la charge à propos de l'évolution de SPIP vers un
support multi bases, souhaitable pour plusieurs d'entre nous.

Je disais hier :

---------8<----------------------------------------------------------
La piste principale pour l'instant est d'ajouter une couche d'accès
aux données, qu'elle soit ou non objet. Une idée serait par exemple
d'avoir des fonctions getArticle(), putArticle(), updateArticle(), et
autres, pour tous les types de données ...

SPIP devant (?) conserver la compatibilité avec PHP3, l'usage d'objet
n'est pas forcément souhaitable.
---------8<----------------------------------------------------------

Je pense que le plus simple, le plus exploitable et le plus extensible
est l'usage des fonctions proposées ci-dessus, avec des tableaux
indexés en paramètre.

Par exemple, au début de 'articles_edit.php3' :

spip_query("UPDATE spip_articles SET date_modif=NOW(), auteur_modif=$connect_id_auteur WHERE id_article=$id_article");

Deviendrait :

$data = array(
'date_modif' => time(),
'auteur_modif' => $connect_id_auteur
);
updateArticle($id_article, $data);

Pour assurer le multi bases, il faut utiliser des types de données
standards, d'où l'usage ici d'un timestamp pour 'date_modif'.

Pour gérer les différentes librairies spécifiques à la base utilisée,
je propose une arborescence comme cela est fait dans d'autres projets:

/SPIP/
/SPIP/ecrire/
/SPIP/ecrire/db/
/SPIP/ecrire/db/mysql/
/SPIP/ecrire/db/oci8/
/SPIP/ecrire/db/pgsql/
...

Avec dans chaque sous-répertoire spécifique de 'db' les librairies
identiques :

connect.php3 (gestion des connexions)
rubrique.php3
article.php3
breve.php3
auteur.php3
...

Chaque script contenant les différentes fonctions à déterminer.

Est-ce que cela vous semble une bonne piste de départ ?

-Nicolas

Jean_Baptiste_FAVRE · Novembre 5, 2002, 11:00

Bonjour aussi,

Bonjour,
---------8<----------------------------------------------------------
La piste principale pour l'instant est d'ajouter une couche d'accès
aux données, qu'elle soit ou non objet. Une idée serait par exemple
d'avoir des fonctions getArticle(), putArticle(), updateArticle(), et
autres, pour tous les types de données ...

SPIP devant (?) conserver la compatibilité avec PHP3, l'usage d'objet
n'est pas forcément souhaitable.
---------8<----------------------------------------------------------

Autant éviter les trolls, donc d'accord

Je pense que le plus simple, le plus exploitable et le plus extensible
est l'usage des fonctions proposées ci-dessus, avec des tableaux
indexés en paramètre.

Par exemple, au début de 'articles_edit.php3' :

spip_query("UPDATE spip_articles SET date_modif=NOW(), auteur_modif=$connect_id_auteur WHERE id_article=$id_article");

Deviendrait :

$data = array(
'date_modif' => time(),
'auteur_modif' => $connect_id_auteur
);
updateArticle($id_article, $data);

Il faudrait faire le point de toutes les requètes sql utilisées par SPIP.
En fonction des SGBD visés, la syntaxe peut être différente, ou les fonctionnalités (procédures stockées par exemple). C'est un
point à prendre en compte.

Pour assurer le multi bases, il faut utiliser des types de données
standards, d'où l'usage ici d'un timestamp pour 'date_modif'.

Oui.

Pour gérer les différentes librairies spécifiques à la base utilisée,
je propose une arborescence comme cela est fait dans d'autres projets:

/SPIP/
/SPIP/ecrire/
/SPIP/ecrire/db/
/SPIP/ecrire/db/mysql/
/SPIP/ecrire/db/oci8/
/SPIP/ecrire/db/pgsql/

On dirait une approche modules ;-D

Avec dans chaque sous-répertoire spécifique de 'db' les librairies
identiques :

connect.php3 (gestion des connexions)
rubrique.php3
article.php3
breve.php3
auteur.php3
...

Chaque script contenant les différentes fonctions à déterminer.

Est-ce que cela vous semble une bonne piste de départ ?

Complétement.
Je pense personnellement qu'il faut dès maintenant se fixer une liste de SGBD à intégrer.
Après ça, faire en sorte que les requètes soient admises par tous. C'est le rôle des librairies.
Voir également ce que l'on peut faire de "spécifique" à tel ou tel SGBD (Proc stockée encore) et surtout tracer les modifs à faire
dans le code SPIP, notemment à l'install.
S'il y a des gens plus spécialisés dans tel ou tel SGBD (et qui y ont accès bien sûr), ils pourraient s'en charger, au moins en
partie.
Je veux bien essayer pour Postgresql, bien que je ne le connaisse que très mal. Ce sera l'occasion d'apprendre ;-))
@+
JB

Grrr · Novembre 5, 2002, 11:29

Des bases XML dans les projets ? (d'où l'abandon de SQL j'imagine)

63438612493668b99328 · Novembre 5, 2002, 11:49

Salut,

Par exemple, au début de 'articles_edit.php3' :

spip_query("UPDATE spip_articles SET date_modif=NOW(),
auteur_modif=$connect_id_auteur WHERE id_article=$id_article");

Deviendrait :

$data = array(
'date_modif' => time(),
'auteur_modif' => $connect_id_auteur
);
updateArticle($id_article, $data);

Pourquoi pas

/SPIP/ecrire/db/
/SPIP/ecrire/db/mysql/
/SPIP/ecrire/db/oci8/
/SPIP/ecrire/db/pgsql/
...

Avec dans chaque sous-répertoire spécifique de 'db' les librairies
identiques :

connect.php3 (gestion des connexions)
rubrique.php3
article.php3
breve.php3
auteur.php3
...

Ca veut dire que la logique est dupliquée dans chaque "backend"
spécifique

Je pense qu'il serait plus intéressant de faire un framework
générique permettant d'abstraire les requêtes (y compris les
jointures ;-)) et qui fasse au plus bas appel à un machin
spécifique par DB. A priori, voir le code actuel de inc_objet_base
et inc_objet, même si y a des trucs tordus.

Surtout, il faut bien se rendre compte que les développeurs actuels
n'utilisent et ne connaissent que MySQL, donc il ne faut pas que
la moindre modif implique de mettre à jour un fichier par DB.

a+

Antoine.

Nicolas_Hoizey1 · Novembre 5, 2002, 1:17

updateArticle($id_article, $data);

Pourquoi pas

Déjà un bon point alors ...

Ca veut dire que la logique est dupliquée dans chaque "backend"
spécifique

Non, juste les accès aux données.

Je pense qu'il serait plus intéressant de faire un framework
générique permettant d'abstraire les requêtes (y compris les
jointures ;-)) et qui fasse au plus bas appel à un machin spécifique
par DB.

Si possible, ce serait pas mal, en effet.

A priori, voir le code actuel de inc_objet_base et inc_objet, même
si y a des trucs tordus.

OK, je vais jeter un oeil dès que possible.

Surtout, il faut bien se rendre compte que les développeurs actuels
n'utilisent et ne connaissent que MySQL, donc il ne faut pas que la
moindre modif implique de mettre à jour un fichier par DB.

C'est bien pour cela qu'il faut laisser uniquement les accès simples
aux données en spécifique.

-Nicolas