! SPIP et le mutl-base

epilibre · Août 25, 2007, 12:01

the interface for multi-bases of Spip is now simplified :

http://trac.rezo.net/trac/spi p/changeset/10113

Here is an attempt to translation (a very poor one, sorry) :

SPIP can be now connected to several SQL databases (MySQL or PostgreSQL) by using the function spip_connect_db . this is systematically called in the file created with the installation, which it is about the principal base (containing the table of the authors in particular) or other bases, managed by SPIP or not. One of the interests of this new interface is that it is enough to copy the file connect.php of a site A in the repertory config of a site B, by giving him the name connectA.php so that the site B has access to the tables of site A, by using in the templates of B the form

<BOUCLE (A:T)….

This possibility introduces some remarks.

in the case of sites which one manage ourself the mutusalisation of the sources, it is then convenient to take only one repertory config common to all sites A B… and to change the name of the connection file (indicated by the constant _FILE_CONNECT’) into connnectA.php , connnectB.php… so that the installation of a site is enough to make a secondary base of the others of it, without having anymore to copy these files.
in the case of distant sites, multi-bases is possible if the SQL server of the secondary site accepts connections of the HTTP server of the principal site, which in general the host providers do not do spontaneously. If they agree, it will be necessary to take care to put in the copy of the connection file the effective IP address of the SQL server, not localhost or 127.0.0.1 as it is often the case in the original of the file.
nothing indicates if a secondary base is managed by SPIP or not, also the compilation of skeletons containing of <BOUCLE (A:T)… does not profit from the usual abbreviations of the principal site: it is necessary to write the prefix of table (thus A:spip_articles and not A: ARTICLES), the implicit joints will not work properly (so you can’t use the id_article criterion in a loop of documents etc) and other facilities ( id_sector for id_rubric in a loop over news, the loops SITES and HIERARCHY will not be included/understood etc). One can consider a new work on the compiler of skeletons to take into account such cases, to even allow the compilation of a local skeleton with a general directive indicating that the tables concerned are elsewhere. The use will say what it will be convenient to develop.
the implementation of multi-bases as described on spip-contrib is obsolete. This interface (which went back in fact to SPIP 1.8) obliged to write several copies of the same functions (in the case of the same db server), put the identifants connection in a repertory not protected by Htacces (not catastrophic, but all the same not very careful) and obliged to program oneself connection to the secondary base.

Compatibility: for those which used neither the prefixes of tables, nor multiple connections, this new interface will be transparent, without need for reinstallation. For the sites where the prefix of table is equal in the name of the base also. For other uses of the prefix of table, just destroy the file connect.php and reinstall. For the sites using the multi-bases in the old manner, read what follows.

In order to allow several connections simultaneously, the $table_prefixe, $spip_mysql_db, $spip_mysql_link, $db_ok lose their roles. A new global variable $connexions is introduced. It is a table indexed by names conventionally indicating databases (names that one will use in the loops of the templates and like the suffix of the corresponding connect file), the principal base being at index 0. Each entry of these tables is itself a table thus formed:

"dB" => name of base SQL 
"prefixes" => prefix of the tables in this base 
"link" => Ressource indicating the connection persistence 
"count" => function of abstraction of the counting of lines in 

"countsel" => function of abstraction for operation COUNT (*) 
"create" => function of abstraction for the creation of table 
"delete" => function of abstraction for the destruction of lines 
"errno" => function of abstraction for the number of error 

"error" => function of abstraction for the error message 
"fetch" => function of abstraction for the extractation 
"fetsel" => function of abstraction for selection then extractation 
"free" => function of abstraction for the release 

"insert" => function of abstraction for insertion 
"listdbs" => function of abstraction to list the bases accessible 
"multi" => function from abstraction for the beacon multi 
"query" => function of abstraction for standard request SQL 

"replaces" => function of abstraction for replacement 
"select" => function of abstraction for the selection 
"selectdb" => function of abstraction to choose a base 
"showtable" => function of abstraction to describe a table 

"update" => function of abstraction to idem modify a line 
"updateq" =>, with gross amounts (apostrophes added with the need)

Thus, $GLOBALS[‹ connexions ›][0][‹ prefix ›] is the equivalent of old the $table_prefix.

The function spip_connect_db admits now an additional argument, the prefix of the tables in the base, which by default is equal to the base. It is called with the installation and in the file connect.php which passes for this reason in version 0.6. The functions spip_query and spip_connect preserve their signatures, but complete a work appearing before in base_db_mysql_dist which it is not thus necessary any more to recopy. Contrary, the function abstract_sql delegates connection to spip_connect, which forces to re-elect possible files inc-connectX.php present in SPIP_PATH in connectX.php in config, but the essence of their contents (clône of the file db_mysql.php ) is to be replaced by a call of spip_connect_db, indicating in particular the type of server (currently MySQL or PG ) the table above exempting to give again these functions.

---------- Forwarded message ----------
From: Committo,Ergo:sum <esj@rezo.net>
Date: 24 août 2007 18:50
Subject: [spip-dev] ! SPIP et le mutl-base
To: spip-core@rezo.net

Du nouveau sur le multi-base en SPIP:

http://trac.rezo.net/trac/spip/changeset/10113

liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip