Portage de SPIP en SQLite

Publié le : 16 décembre 2007 – Dernière modification le 21 décembre 2021 – par Déesse A. , Matthieu Marcillaud, NicolasR – 6

3 votes

Après PostGreSQL c’est au tour de SQLite d’être porté par SPIP

Sommaire

SQLite
Une couche d’abstraction pour gérer les différents serveurs SQL
Déroulement technique de l’installation
Différences entre les versions 2.x et 3.x de SQLite
Dépôts réalisant le portage :
Pour en savoir plus sur SQLite
Lecture des bases de données SQLite
Support de tests

C’était en germe et déjà évoqué dans l’annonce du Portage de SPIP en PostGres

SQLite est maintenant livré en standard en PHP, et ça permettrait d’avoir un site « tout fichier » [1] ; pour les petits sites (et les gros sous réserves de performances acceptables) cela offrirait d’importantes facilités dans la maintenance, les sauvegardes, l’hébergement etc ...

C’est maintenant chose faite

SQLite

SQLite est un serveur de base de données qui a la particularité de sauvegarder une base dans un fichier unique. Ce fichier peut être récupéré et envoyé par FTP sur son site. La gestion de SQLite par PHP est présente depuis PHP 5 pour la version 2.x et PHP 5.1 pour la version 3.x.

SQLite est maintenant géré, comme MySQL et PostGreSQL par SPIP. Ce nouveau portage permet de lire ou de créer une base de données au format SQLite 2.x et SQLite 3.x (ces formats ne sont pas compatibles entre eux).

Une sauvegarde simple et rapide de la base de donnée :

Comme évoqué dans l’annonce Portage de SPIP en PostGres, SQLite peut faciliter grandement la gestion des sauvegardes des petits sites, et éventuellement des gros, si les performances de SQLite se révèlent acceptables, puisque la sauvegarde de la base de données consiste à copier simplement un fichier du serveur vers sa sauvegarde.

Une couche d’abstraction pour gérer les différents serveurs SQL

Grâce aux nouvelles fonctions concernant les serveurs de bases de données, SPIP peut se connecter à d’autres serveurs SQL que MySQL. Il faut pour cela que le SPIP connaisse la syntaxe des requêtes à transmettre au serveur SQL. C’est le rôle des fichiers contenus dans le dossier ecrire/req/.

Ces fichiers (mysql.php, pg.php, sqlite_generique.php) assurent la traduction entre les fonctions génériques d’accès aux bases de données proposées par SPIP ( fonctions sql_*() ), que l’on appelle la « couche d’abstraction », et la syntaxe des requêtes du serveur demandé.

Un premier portage pour PostGreSQL

Le premier portage a concerné PostGreSQL (historiquement un des premiers serveurs SQL, et un des rares a être entièrement sous licence GPL), ce qui a permis de définir l’indispensable signature des fonctions d’abstractions sql_*() permettant de jongler entre les différentes versions de SQL. Ces fonctions étant stabilisées, d’autres portages peuvent se réaliser.

Le cas de SQLite

Ajouter le portage de SQLite (versions 2.x et 3.x) a donc consisté à créer les fichiers sqlite2.php et sqlite3.php dans le dossier ecrire/req/, qui pour leur cas, appellent un fichier générique qui gère les versions 2.x et 3.x de SQLite : sqlite_generique.php

Un dernier fichier sqlite_fonctions.php contient un ensemble de fonctions php qui sont automatiquement déclarées au serveur SQLite par SPIP et qui peuvent alors être utilisées dans les requêtes. Cet outil est très important (et c’est un point fort de SQLite) car de base, SQLite ne gère que très peu de fonctions SQL (par exemple, il ne gère pas NOW()).

Déroulement technique de l’installation

Lors de la procédure d’installation du site, SPIP cherche les modules php concernant SQLite et essaie éventuellement de les charger (nécessaire sur Ouvaton par exemple). Il propose alors, en plus de MySQL et PostGreSQL de se connecter à SQLite 2 et/ou SQLite 3 en fonction des extensions php trouvées (’sqlite’ pour SQLite 2, ’pdo’ et ’pdo_sqlite’ pour SQLite3)

SPIP créera automatiquement (s’il le peut) un répertoire défini par la constante _DIR_DB (qui est par défaut _DIR_ETC/bases/, donc le répertoire config/bases/) pour y stocker les bases de données SQLite qu’il suffixe par .sqlite (quelque soit la version).

Déclarer une autre base de donnée

Il est possible de déclarer d’autres bases de données que la base avec laquelle SPIP a été installé, en utilisant un formulaire de l’interface privée accessible par : Configuration > Maintenance du site > Déclarer une nouvelle base.

Lorsqu’une nouvelle base est déclarée, par exemple toto.sqlite, ou une base nommée ’toto’ en MySQL ou PostGreSQL, deux nouvelles choses sont alors possibles :

Toutes les boucles du site peuvent êtres remplacées par le contenu de la base déclarée en ajoutant le paramètre connect dans l’url : http://domaine.tld/?connect=toto
Une boucle du squelette peut afficher le contenu de la base déclarée en utilisant la syntaxe : <BOUCLE_x(toto:TABLE)>#CHAMP</BOUCLE_x>

Différences entre les versions 2.x et 3.x de SQLite

Les versions 2 et 3 de SQLite se distinguent par 3 choses :

les fichiers des bases ne sont pas compatibles entre eux. Cela signifie qu’une base au format sqlite2 ne pourra pas être lue par sqlite3 et vice et versa.
Des syntaxes SQL ne sont pas présente en SQLite2 (mais sont néanmoins gérées par le portage SPIP) :
- IF NOT EXISTS pour les requetes CREATE TABLE
- ADD column et RENAME [TO] column pour les requêtes ALTER TABLE table
PHP utilise une classe PDO pour gérer SQLite 3 alors qu’il utilise des fonctions sqlite_*() pour sqlite 2. L’objet PDO/SQLite3 n’a pas de fonction pour compter le nombre de lignes d’une requete SELECT, il a été nécessaire de l’émuler pour le portage.

Dépôts réalisant le portage :

Pour en savoir plus sur SQLite

- http://fr.wikipedia.org/wiki/SQLite
- ChangeLog SQLite
- PHP et SQLite
- PHP et PDO
- Document de travail pour le portage SQLite

Lecture des bases de données SQLite

Un excellent module pour Thunderbird ou Firefox permet de gérer les bases de données SQLite3 : SQLite Manager

Support de tests

Pour faciliter un peu les tests du portage, un tout petit squelette sqlAdmin.html a été créé (On peut le trouver sur la zone). Il permet de faire des requêtes sur le « serveur » de son choix en agissant sur la variable $connect. Ah, évitez d’avoir des « . » dans les noms de ces fichiers de connexions genre « domaine.tdl.php » car SPIP n’aime pas dans la variable &connect.

Notes

[1] NDLR : sans besoin de base réelle, il s’agirait d’une émulation de MySQL ici, d’où les contraintes de performances

5 ans 1 an 3 mois Sans limite

par date

Aucune discussion

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
- version de SPIP, en bas de la partie privée
- version du plugin testé et des éventuels plugins nécessités
- version de PHP (exec=info en partie privée)
- version de MySQL / SQLite
Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?

Nom [Se connecter]

Courriel (non publié)

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

Texte de votre message

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Prévenez-moi de tous les nouveaux commentaires de cette discussion par email

Ajouter un document

Extensions autorisées : gif, jpg, png

Suivre les commentaires : |