SPIP-Contrib

SPIP-Contrib

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

279 Plugins, 195 contribs sur SPIP-Zone, 126 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.
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

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
  • 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

Tout afficher

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 ?
  • [Se connecter]

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

  • Saisies

    27 mars 2010 – 362 commentaires

    Introduction Créer un formulaire est une tâche toujours un peu répétitive : les champs ont souvent les mêmes propriétés, le même accompagnement (message d’erreur, explication, ...) et la même structure HTML. Ce plugin est un outil pour les développeurs (...)

  • Galleria (fr)

    16 novembre 2011 – 132 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é (...)

  • Plugin Vidéo(s)

    23 novembre 2010 – 509 commentaires

    Interface de gestion et modèle d’insertion des vidéos : Dailymotion Vimeo Youtube Modèle de la balise HTML5 video avec alternative flash html5media : Lecture HTML5/Flash pour tout navigateur des fichiers MP4/H264/Ogg/WebM/Mkv Support (...)

  • Sarka-SPIP 3

    15 septembre 2009 – 196 commentaires

    Si la lignée 3 de Sarka-SPIP a été l’occasion de refaire presque entièrement le code du squelette elle continue à évoluer et à s’améliorer au fil des versions. Nous ne saurions trop conseiller aux nouveaux utilisateurs - et aussi aux anciens - d’utiliser (...)

  • Formidable, le générateur de formulaires

    23 janvier 2012 – 1351 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 (...)