Dans l'espoir que cette fonctionnalité sera intégrée à la prochaine version
de SPIP,
voici le fichier des modifications à introduire : poursuivant mes tests,
j'y ai ajouté 2 modifs.
A+
François
Spip_Prefix_Modifs.txt (4.49 KB)
Salut,
merci pour ton boulot, c'est vraiment une fonctionnalité pratique. Je vais
tester tes changements en local dès que possible ! En espérant que ce soit
intégrer dans SPIP d'ici là !!!! Ce serait vraiment bien et utile à plein de
gens comme qui ont qu'une base MySQL et plein de projets !
Amicalement,
Salut François,
Merci beaucoup pour la proposition. Le problème c'est que c'est beaucoup
trop brutal comme façon de procéder : ça change tout le code à la louche,
et après les erreurs sont rectifiées dans l'autre sens.
A mon avis, pour implémenter cette fonctionnalité, il serait préférable
d'ajouter une fonction d'abstraction de base de données toute simple,
qui changerait automatiquement le préfixe des tables dans la requête.
Du genre, sans tester :
function spip_query($query) {
global $table_prefix;
eregi('[[:space:]](VALUES|WHERE)[[:space:]].*$', $query, $regs);
if ($suite = $regs[0]) {
$query = substr($query, 0, -strlen($suite));
}
$query = ereg_replace('[[:space:]]spip_', ' '.$table_prefix.'_', $query) . $suite;
return mysql_query($query);
}
Je ne pense pas que ça induise un ralentissement, comparé à la durée de la
requête en elle-même. La seule chose à vérifier est de toujours utiliser
des alias (spip_articles AS articles) quand le nom d'une table est inclus
dans le WHERE. (il ne faut pas qu'une donnée contenant la chaîne 'spip_'
soit modifiée par cette fonction)
C'est aussi une question de commodité de développement : est-il préférable :
- de changer toutes les requêtes pour remplacer 'spip_' par un appel de
$spip_prefix
- ou de remplacer tous les mysql_query par des spip_query, et ensuite de
simplement faire gaffe à la règle des alias
a+
Antoine.
il serait préférable d'ajouter une fonction d'abstraction de base de
données toute simple, qui changerait automatiquement le préfixe des
tables dans la requête
Et qui permettrait aussi du même coup d'utiliser d'autres SGBD, aux
quelques requêtes spécifiques MySQL à corriger prêt. Il me semble
avoir déjà vu plusieurs personnes intéressées par PostgreSQL, par
exemple.
On peut soit développer des fonctions particulières à SPIP, comme la
'spip_query' proposée par Antoine, soit s'appuyer sur des classes
existantes.
Nous avons dans phpMyChat des classes pour MySQL, PostgreSQL et ODBC,
donc si ça vous chante, piochez dedans ... 
-Nicolas
Hello,
> Et qui permettrait aussi du même coup d'utiliser d'autres SGBD, aux
> quelques requêtes spécifiques MySQL à corriger prêt. Il me semble
> avoir déjà vu plusieurs personnes intéressées par PostgreSQL, par
> exemple.
Ouip.
> Nous avons dans phpMyChat des classes pour MySQL, PostgreSQL et ODBC,
> donc si ça vous chante, piochez dedans ...
Je viens de regarder, apparemment on ne peut avoir qu'une requête ouverte
à la fois (l'id de requête est stocké dans la classe d'abstraction db).
Pour SPIP, on a impérativement besoin de pouvoir ouvrir plusieurs requêtes
sans fermer les précédentes (y compris SELECT).
Il faudrait une couche d'abstraction (classes ou fonctions, peu importe) :
- compatible PHP3
- pas trop compliquée à utiliser
- qui autorise plusieurs requêtes ouvertes à la fois
a+
Antoine.
Je viens de regarder, apparemment on ne peut avoir qu'une requête
ouverte à la fois (l'id de requête est stocké dans la classe
d'abstraction db).
C'est stocké dans la classe, oui, il le faut bien, mais ce n'est pas
en statique, donc rien n'empêche d'avoir plusieurs instances de la
classe.
Il faudrait une couche d'abstraction (classes ou fonctions, peu
importe) :- compatible PHP3
- pas trop compliquée à utiliser
- qui autorise plusieurs requêtes ouvertes à la fois
C'est donc bien le cas ...
-Nicolas
Nicolas Hoizey wrote:
C'est stocké dans la classe, oui, il le faut bien, mais ce n'est pas
en statique, donc rien n'empêche d'avoir plusieurs instances de la
classe.
Oui mais ça fait plusieurs connexions non ?
rien n'empêche d'avoir plusieurs instances de la classe
Oui mais ça fait plusieurs connexions non ?
Pas avec Apache, qui doit représenter 99% des plate-formes utilisées
avec SPIP, donc je ne pense pas que ce soit un problème.
Quoi qu'il en soit, il serait sans doute judicieux un jour de balancer
cette compatibilité avec PHP3, et de profiter de :
- vitesse d'exécution x 10
- fonctionnalités natives supplémentaires
- PEAR:DB et autres composants magiques
- ...
Notez que j'ai un site SPIPé sur l'un des derniers hébergeurs encore
limité à PHP3 (L'Autre Net, pour le nommer), donc je serais moi-même
limité à la version 1.4 sur ce site, mais l'avancée que cela
représenterait pour une 2.x en vaut à mon avis la chandelle ...
-Nicolas
Oui mais ça fait plusieurs connexions non ?
Pas avec Apache, qui doit représenter 99% des plate-formes utilisées
Heu, comment ça ?
Nicolas Hoizey wrote:
Et qui permettrait aussi du même coup d'utiliser d'autres SGBD, aux
quelques requêtes spécifiques MySQL à corriger prêt. Il me semble
avoir déjà vu plusieurs personnes intéressées par PostgreSQL, par
exemple.
Je viens de faire un tour sur pas loin d'une dizaines de machins
d'abstraction, aucun n'est vraiment satisfaisant. Il y en a deux
quand même qui valent le coup : celui de daCode, et un autre du
nom de lib_db_abstraction.
Surtout, le gros problème auquel on va faire face est que certaines
constructions ont l'air farouchement mysql-centriques.
Amicalement
Antoine.
Je viens de faire un tour sur pas loin d'une dizaines de machins
d'abstraction, aucun n'est vraiment satisfaisant.
Je suis bien d'accord, c'est dur de faire une bonne abstraction ...
Les meilleures à l'heure actuelle en PHP sont à priori PEAR:DB,
Metabase et ADODB, mais aucune n'est compatible PHP3 bien évidemment.
Surtout, le gros problème auquel on va faire face est que certaines
constructions ont l'air farouchement mysql-centriques.
Tu parles de SPIP, là, je suppose. En effet, il faudra revoir
certaines logiques de requêtes pour les rendre "universelles".
-Nicolas
Bon j'ai terminé (enfin je pense), je commite. Attention, ça va faire
des diffs gros comme ça (bcp de modifs).
Ce qu'il faut savoir :
- il faut donc maintenant toujours utiliser spip_query() au lieu de
mysql_query()
- comme prévu, la seule chose à laquelle il faut veiller, c'est de ne
pas utiliser directement le nom des tables dans un WHERE, mais un alias
(avec la syntaxe spip_table AS truc). Ca arrive uniquement quand on fait
une requête avec plusieurs tables.
Exemple, ne pas écrire :
SELECT spip_articles.* FROM spip_articles, spip_auteurs_articles
WHERE spip_articles.id_article = spip_auteurs_articles.id_article
AND spip_auteurs_articles.id_auteur = 1
Mais :
SELECT articles.* FROM spip_articles AS articles, spip_auteurs_articles AS lien
WHERE articles.id_article = lien.id_article AND lien.id_auteur = 1
Ca tombe bien, c'est ce qu'on faisait déjà en général
- maintenant que toutes les requêtes sont centralisées dans une fonction
à nous, ça permet de prévoir des trucs amusants. Par exemple, pour savoir
ce qui prend du temps dans un affichage, on peut afficher simplement la
liste des requêtes effectuées sur la base.
J'espère que ça n'apportera pas de complications supplémentaires, mais
y a pas de raisons....
a+
Antoine.
Oui mais ça fait plusieurs connexions non ?
Pas avec Apache, qui doit représenter 99% des plate-formes
utiliséesHeu, comment ça ?
A priori, un process Apache avec PHP en module qui ouvre une connexion
vers MySQL (je ne sais pas pour les autres) la conserve pour d'autres
requêtes si elles utilisent le même identifiant, et cela même si on
n'utilise pas pconnect.
Je vais essayer de creuser le sujet pour confirmer ...
-Nicolas
Oui, je pense qu'on est beaucoup à avoir de grosses attentes
de ce côté là.
Ce serait vraiment très bien que ce soit intégré à la prochaine
version si ça ne pose pas de pb majeur.
Donatien
En espérant que ce soit
intégrer dans SPIP d'ici là !!!! Ce serait vraiment bien et utile à plein de
gens comme qui ont qu'une base MySQL et plein de projets !
Amicalement,
Je suis 100% d'accord avec la réalisation de cette fonction.
J'utilise moi-même pour mes applis une interface compatible
mSQL, MySQL et Oracle.
Je suis évidemment preneur d'une version à tester...
A+
François
François G-Hamonno wrote:
> Je suis évidemment preneur d'une version à tester...
Le multi-base est apparu dans la version suivante :
http://rezo.net/spip-dev/devel/SPIP_2002-04-15-0430.zip
Le préfixe est à régler au début de ecrire/inc_version.php3,
variable $table_prefix. Evidemment, c'est "spip" par défaut.
(oui, inc_version devient un peu fourre-tout... ;-))
Il y a deux petits bugs sur les mots-clés dans cette version,
pour le reste on attend tes observations.
Amicalement
Antoine.