SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

282 Plugins, 197 contribs sur SPIP-Zone, 320 visiteurs en ce moment

Accueil > Documentation > Tutoriaux Multitables & Multibases > Multibases et Multitables - Les annonces

Multibases et Multitables - Les annonces

20 octobre 2007 – par NicolasR – commentaire

Attention, cette page de documentation est incomplète... Vous devrez donc découvrir et expérimenter par vous-même. Des liens à la fin permettent d’accéder à d’autres documentations.
Soyez sympa, pensez à revenir compléter cette page ;-)

La reprise des différentes annonces sur les Multibases ou le le Multitables sur Trac ou la liste spip-core, par ordre antéchronologique.


Nota SPIP-Contrib : ces divers mouvements de code entre les versions 1.9.2 et 1.9.3 de SPIP ne sont pas sans influences sur les plugins, dont nombreux devront être mis à jour pour rester comptatibles . Voir à ce propos Compatibilité des plugins entre SPIP 1.9.2 et SPIP 1.9.3

Dernière incompatibilité avant l’autoroute


De : "Committo,Ergo:sum"
Date : 1 novembre 2007 10:36:45 GMT+01:00
À : SPIP-dev SPIP <spip-dev>
Objet : [spip-dev] Dernière incompatibilité avant l’autoroute

Bonjour à tous,

Le portage de SPIP en PostGres a permis de valider la jeu de fonctions d’abstractions élaboré ces derniers mois, et la rédaction de leur documentation est en cours sur spipnet (voir déjà http://www.spip.net/ecrire/?exec=ar... pour l’interface utilisateur, et bientot celle du programmeur). Comme toujours, une telle rédaction fait apparaître des scories dans les spécifications, qu’il semble indispensable d’éliminer pour offrir une interface la moins rebutante possible.

La fonction spip_abstract_select, ancêtre de sql_select, avait été introduite dès les premières versions du compilateur de SPIP, et uniquement pour lui. Avec la systématisation des appels aux fonctions d’abstractions même dans l’espace privé, la signature de cette fonction se révèle malcommode pour les humains, car trois de ces cinq derniers arguments optionnels sont toujours vides : uns éventuelle sous-requete (pour le compilateur qui n’en a meme plus besoin à présent), et le nom de la boucle et de la table dans un squelette (utile seulement au débusqueur). Ces deux informations sont finalement gérées en amont, ce qui permet de ramener le nombre d’arguments de cette fonction a « seulement » 8.

Ce changement peut introduire une incompatibilité pour les extensions de SPIP, mais elle devrait être réduite car elle ne concerne que les appels utilisant une clause HAVING (assez rare) et ceux explicitant le serveur SQL (peu fréquent car le multi-serveur n’était pas très commode d’utilisation avant l’unification récente des fichiers de connexion).

Bonne expérimentation à tous

Committo,Ergo:Sum

Portage de SPIP en PostGres


De : "Committo,Ergo:sum" <esj>
Date : 18 octobre 2007 15:54:09 GMT+02:00
À : spip-core at rezo.net
Objet : [spip-dev] ! Portage de SPIP en PostGres

Voir l’annonce complète Portage de SPIP en PostGres

Déclaration des bases supplémentaires


De : "Committo,Ergo:sum" <esj>
Date : 12 octobre 2007 15:19:36 GMT+02:00
À : spip-core@rezo.net
Objet : ! [spip-dev] Déclaration des bases supplémentaires

En complément du travail annoncé sur les multiples manières d’utiliser des bases supplémentaires dans les squelettes, le formulaire d’installation de SPIP propose de déclarer ces bases, ce qui provoque la création des fichiers de connexion ad hoc. Tout est ainsi clic en main.

Voir http://trac.rezo.net/trac/spip/chan... et suivants.

Petits changements dans la balise EXPOSE et le mutli-base, et quelques nouveautés de la future 1.9.3


De : "Committo,Ergo:sum" <esj>
Date : 3 octobre 2007 12:43:39 GMT+02:00
À : spip-core at rezo.net
Objet : ! [spip-dev] Petits changements dans la balise EXPOSE et le mutli-base, et quelques nouveautés de la future 1.9.3

La balise EXPOSE ne se limite plus aux tables standards de SPIP de clé primaire id_*, considère id_groupe comme la hiérarchie de id_mot. Elle permet aussi de référencer la clé primaire d’une boucle de niveau supérieur, ce qui est plus général qu’auparavant mais induit un comportement parfois différent d’auparavant dans les cas limites qui étaient de toutes façons pas toujours bien gérés. Voir :
-  http://trac.rezo.net/trac/spip/chan...
-  http://trac.rezo.net/trac/spip/chan...

Les possibilité d’interrogation d’autres tables, voir d’autres serveurs, que celles standard de SPIP ont amené qq changements dans les noms de fichiers, de fonctions et de constante (rien de changé pour une utilisation std de SPIP). Voir les dépots suivants pour les modifications et nouvelles fonctionnaltiés (attention, les spécifications les plus récentes sont évidemment les seules valables à présent) :
-  trac/spip/changeset/10479
-  trac/spip/changeset/10463
-  trac/spip/changeset/10458
-  trac/spip/changeset/10457
-  trac/spip/changeset/10183
-  trac/spip/changeset/10113

Profitons de l’occasion pour signaler les nouveautés récentes (sans parler du portage PostGres auquel il ne manque plus que le traitement des mises à jours de la BD).

Il est possible de limiter une sauvegarde à une rubrique, et de fusionner le résultat avec une base d’un autre site, éventuellement en dépubliant les objets importés.

Le critère petition permet de retrouver les articles ayant une petition, eventuellement avec certaines propriétés, voir http://trac.rezo.net/trac/spip/chan...

Après le multi-base, le multi-squelette


De : "Committo,Ergo:sum"
Date : 30 août 2007 18:20:27 GMT+02:00
À : spip-core at ezo.net
Objet : ! [spip-dev] Après le multi-base, le multi-squelette

trac/spip/changeset/10183
voir aussi
trac/spip/ticket/716

Interface unique pour le multi-base.


trac/spip/changeset/10113
Date : 24.08.2007 18:48:39 (2 mois auparavant)
Auteur : esj at rezo.net

SPIP peut à présent se connecter à plusieurs serveurs SQL (MySQL ou PG) en utilisant systématiquement la fonction spip_connect_db appelée dans le fichier créé à l’installation, qu’il s’agisse de la base principale (contenant notamment la table des auteurs) ou d’autres bases, gérées par SPIP ou non. Un des intérêts de cette nouvelle interface est qu’il suffit de copier le fichier connect.php d’un site A dans le répertoire config d’un site B, en lui donnant le nom connectA.php pour que le site B ait accès aux tables du site A, en utilisant dans les squelettes de B la forme
<BOUCLE(A:T)....

Cette possibilité appelle quelques remarques.

  • dans le cas de sites dont on gére soi-même la mutusalisation des sources, il est alors opportun de prendre un seul répertoire config commun à tous les sites A B ... et de changer le nom du fichier de connexion (indiqué par la constante _FILE_CONNECT’) en connnectA.php, connnectB.php ... pour que l’installation d’un site suffise à en faire une base secondaire des autres, sans plus avoir besoin de copier ces fichiers.
  • dans le cas de sites distants, le multi-base est possibile si le serveur SQL du site secondaire accepte les connexions du serveur Http du site principal, ce qu’en général les hébergeurs ne font pas spontanément. S’ils en sont d’accord, il faudra veiller à mettre dans la copie du fichier de connexion l’adresse IP effective du serveur SQL, pas localhost ou 127.0.0.1 comme c’est souvent le cas dans l’original du fichier.
  • rien n’indique si une base secondaire est gérée par SPIP ou non, aussi la compilation de squelettes contenant des <BOUCLE(A:T)... ne bénéficie pas des abréviations usuelles du site principal : il faut écrire le préfixe de table (donc A:spip_articles et pas A:ARTICLES), les jointures implicites ne fonctionneront pas (pas de critère id_article dans une boucle de documents etc) et autres facilités (id_secteur pour id_rubrique dans une boucle de brèves, les boucles SITES et HIERARCHIE ne seront pas comprises etc). On peut envisager un nouveau travail sur le compilateur de squelettes pour prendre en compte le cas, voire permettre la compilation d’un squelette local avec une directive générale indiquant que les tables concernées sont ailleurs. L’usage dira ce qu’il sera opportun de développer.
  • la mise en oeuvre du multi-base telle que décrite sur spip-contrib est obsolète. Cette interface (qui remontait en fait à SPIP 1.8) obligeait à écrire plusieurs copies des mêmes fonctions (dans le cas d’un même serveur), mettait les identifants de connexion dans un répertoire non protégé par un Htacces (pas catastrophique, mais tout de même peu prudent) et obligeait à programmer soi-même la connexion à la base secondaire.

Compatibilité : pour ceux qui n’utilisaient ni les préfixes de tables, ni les connexions multiples, cette nouvelle interface sera transparente, sans nécessité de réinstallation. Pour les sites où le préfixe de table est égal au nom de la base également. Pour d’autres utilisations du préfixe de table, détruire le fichier connect.php et réinstaller. Pour les sites utilisant le multi-bases ancienne manière, lire ce qui suit.

Afin de permettre plusieurs connexions simultanément, les globales $table_prefixe, $spip_mysql_db, $spip_mysql_link, $db_ok perdent leurs rôles. Une nouvelle globale $connexions est introduite. C’est un tableau indexé par des noms conventionnels désignant les bases (noms qu’on utilisera dans les boucles des squelettes et comme suffixe du fichier connect correspondant), la base principale étant à l’index 0. Chacune des entrées de ces tableaux est elle-même un tableau ainsi formé :


’db’ => nom de la base SQL
’prefixe’ => préfixe des tables dans cette base
’link’ => Ressource indiquant la connexion persistance
’count’ => fonction d’abstraction du comptage de lignes dans
’countsel’ => fonction d’abstraction pour l’opération COUNT(*)
’create’ => fonction d’abstraction pour la création de table
’delete’ => fonction d’abstraction pour la destruction de lignes
’errno’ => fonction d’abstraction pour le numéro d’erreur
’error’ => fonction d’abstraction pour le message d’erreur
’fetch’ => fonction d’abstraction pour l’extractation
’fetsel’ => fonction d’abstraction pour sélection puis extractation
’free’ => fonction d’abstraction pour la libération
’insert’ => fonction d’abstraction pour l’insertion
’listdbs’ => fonction d’abstraction pour lister les bases accessibles
’multi’ => fonction d’abstraction pour la balise multi
’query’ => fonction d’abstraction pour requête SQL standard
’replace’ => fonction d’abstraction pour remplacement
’select’ => fonction d’abstraction pour la sélection
’selectdb’ => fonction d’abstraction pour choisir une base
’showtable’ => fonction d’abstraction pour décrire une table
’update’ => fonction d’abstraction pour modifier une ligne
’updateq’ => idem, avec valeurs brutes (apostrophes rajoutés au besoin)

Ainsi, $GLOBALS[’connexions’][0][’prefixe’] est l’équivalent de l’ancien $table_prefix.

La fonction spip_connect_db admet à présent un argument supplémentaire, le préfixe des tables dans la base, qui par défaut est pris égal à la base. Elle est invoquée à l’installation et dans le fichier connect.php qui passe pour cette raison en version 0.6. Les fonctions spip_query et spip_connect conservent leur signatures, mais réalisent un travail figurant auparavant dans base_db_mysql_dist qu’il n’est ainsi plus nécessaire de recopier. A l’inverse, la fonction abstract_sql délègue la connexion à spip_connect, ce qui impose de renommer les éventuels fichiers inc-connectX.php présents dans SPIP_PATH en connectX.php dans config, mais l’essentiel de leur contenu (clône du fichier db_mysql.php) est à remplacer par un appel de spip_connect_db, indiquant notamment le type du serveur (MySQL ou PG actuellement) le tableau ci-dessus dispensant de redonner ces fonctions.

Voir aussi sur le Carnet Wiki de ce site : Comment porter un plugin d’un SPIP version 1.9 à un SPIP V 2.0

Retour en haut de la page

Vos commentaires

  • Le 9 mars 2010 à 12:01, par Pierre-Jean En réponse à : Multibases et Multitables - Les annonces

    Bonjour,

    Je me familiarise avec les notions de multi serveurs et de multi bases, mais ne trouver pas de réponse : par ou commencer pour indiquer à spip que certaines tables sont à utiliser (lecture et écriture) ailleurs que sur l’installation standard ?

    Sur une base, mon site normal, sur l’autre les articles syndiqués.

    Je dois séparer les articles syndiqués sur une ou plusieurs BDD dédiés car trop volumineuses...

    Des pistes ?

    Merci pour votre aide,

    Pierre-Jean

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Plugin « masquer »

    7 juillet 2010 – 25 commentaires

    Ce plugin permet de masquer sur le site public un contenu auquel le mot-clé « masquer » a été attribué. Le contenu, rendu invisible sur le site public, est cependant toujours présent et accessible à vos visiteurs si vous leur donnez le bon lien. Il (...)

  • Réservation d’événements

    16 mars – 33 commentaires

    Ce plugin permet d’offrir aux visiteurs de s’inscrire pour un évènement du plugin Agenda et de gérer les réservations enregistrées. Installation Le plugin s’installe comme n’importe quel plugin. il nécessite : Agenda API de vérification Facteur (...)

  • Adaptive Images

    15 novembre 2013 – 44 commentaires

    Un plugin pour permettre aux sites responsive d’adapter automatiquement les images de la page à l’écran de consultation. Adaptive Images, que l’on pourrait traduire par Images adaptatives, désigne la pratique qui vise à adapter les taille, résolution (...)

  • Galleria (fr)

    16 novembre 2011 – 145 commentaires

    Une galerie d’image qui utilise la librairie javascript Galleria. Description Ce plugin vous permet d’ajouter des galeries d’images à vos articles. La galerie créée utilise la librairie javascript Galleria. Le plugin propose un modèle nommé (...)

  • Formidable, le générateur de formulaires

    23 janvier 2012 – 1609 commentaires

    Un générateur de formulaires facilement configurable pour les non-informaticiens et facilement extensible pour les développeurs. Introduction L’objectif était de créer un plugin permettant de générer des formulaires. Historiquement, 2 plugins avaient (...)