Carnet Wiki

sqliteVoir aussi Accéder aux bases SQLite...

sqliteVoir aussi Accéder aux bases SQLite...

sqliteVoir aussi Accéder aux bases SQLite kevin

Intérêts et limites de SQLite

Installer un SPIP avec SQLite est immédiat : pas besoin de créer une base dans un autre outil, pas besoin de login ni de mot de passe. Cela simplifie l’expérience de la première installation. La base de données Sqlite est dans un fichier (rangé dans config/bases). Du coup, il est facile de copier ou transporter tout son site : il suffit de copier le répertoire de SPIP pour disposer d’un backup complet de tout le site (fichiers + base) que l’on peut réinstaller autre part. _ Mais certains hébergements (mutualisés, tres utilisés) peuvent accepter une installation SQLite (discretement implémentée en MySQL) : bonjour les problèmes ! Sur un hébergement mutualisé, SQLite peut être moins rapide que mySQL, selon la configuration du serveur, en raison des accès disques : sur un mutualisés, les accès aux fichiers sont parfois lents car déportés sur le réseau, or avec sqlite, la base de donnée est dans un fichier. Raisonnement erroné : sur un hébergement mutualisé mySQL est aussi sur un autre serveur et les accès se font par réseau comme pour SQLite. Cela ne change rien en relatif mySQL vs SQLite que l’on soit sur un dédié ou sur un mutualisé. Le raisonnement d’abord porte sur la simultanéité des écritures, impossibles sur UN fichier regroupant toutes les tables de SPIP. (en particulier les tables d’enregistrement des statistiques de visites) et devrait précier le ’volume’ des données transmises entre le serveur du/des fichiers et le serveur Apache embarquant la bibliothèque SQLite.

Passages de SQLite à mySQL ou réciproquement

Le passage de mySQL vers SQLite (via dump SQLite) est simple et sans risque Si vous avez un site sous mySQL il suffit de faire une sauvegarde depuis le site et de la réimporter dans un site installé avec SQLite. Le passage dans ce sens est généralement très bien supporté et ne pose pas de problèmes. Le passage de SQLite à mySQL (via un dump SQLite) est problématique La structure d’une base SQLite est plus pauvre que celle d’une base mySQL et il est difficile de recréer la structure de la base mySQL à partir de celle de SQLite sans risque de bugs ultérieurs. En attendant que le passage de mySQL à SQLite soit automatiquement pris en charge, il existe une procédure manuelle. Procédure manuelle pour passer sa base de SQLite à mySQL : -* Sur le site 1 installé avec SQLite faire une sauvegarde dans tmp/dump/dump1.sqlite -* Installer un site 2 avec mySQL avec tout les mêmes plugins (mêmes tables dans la base de donnée) -* Sur ce site 2 installé avec mySQL faire une sauvegarde dans tmp/dump/dump2.sqlite -* Exporter la table spip_meta du dump2.sqlite dans un fichier : _ echo ".dump spip_meta" | sqlite3 dump2.sqlite > metadump2.txt -* Supprimer la meta de structure dans dump1.sqlite : _ echo "delete from spip_meta where nom='dump_structure_temp';" | sqlite3 dump1.sqlite -* Mettre à jour la table spip_meta dans dump1.sqlite : _ sqlite3 dump1.sqlite < metadump2.txt -* Importer le dump1.sqlite dans le site 2 sous mySQL depuis l’interface SPIP. Cette procédure repose sur le fait que les bases du site 1 et du site 2 ont les mêmes tables avec les mêmes champs. Il faut donc faire bien attention à avoir tous les mêmes plugins installés. Procédure manuelle simplifiée (v2) pour passer sa base de SQLite à mySQL : -* Sur le site 1 installé avec SQLite faire une sauvegarde dans tmp/dump/dump1.sqlite -* Supprimer la meta de structure dans dump1.sqlite : _ echo "delete from spip_meta where nom='dump_structure_temp';" | sqlite3 dump1.sqlite -* Installer un site 2 avec mySQL avec tout les mêmes plugins actifs (mêmes tables dans la base de donnée) -* Importer le dump1.sqlite dans le site 2 sous mySQL depuis l’interface SPIP. Autre solution (signalée par G.Vincent ) : voir http://stackoverflow.com/a/13365275 (nécessite Python).

Administration

Une gestionnaire de base de données en ligne ? http://www.adminer.org Un équivalent léger de phpmyadmin pour sqlite, utilisable en local uniquement (mamp, easyphp etc) est un plugin de firefox : sqlite manager et codev, un plugin pour le navigateur chrome Si on gère son serveur sous Ubuntu, il faut installer sqlite3 et pas sqlite ! ça se fait avec : sudo pecl install pdo_sqlite

Cas particuliers

-# certaines extensions de mysql ne sont pas disponible pour sqlite : notamment geométrie (pour GIS), fullsearch -# sur une mutualisation SPIP, les 2 formats de données ne cohabitent pas (sur des sites différents) par défaut. Selon un témoignage, il est toutefois possible de le faire en choisissant un des 2 dans mes_options. (SpipFactory) je précise que l’on peu avoir des spip en SQLite & mySQL sur une mutualisation par contre c’est le fichier d’installation d’un nouveau site (plugin mutualisation) ou est définie le choix. Donc soit on choisie d’installer ces sites en SQLite ou en mySQL. chez moi les sites sont installé maintenant en mySQL alors que 25 sites tourne encore en SQLite..


Ci-dessous le retour d’expérience de l’essai de passage d’un site spip sous SQLite a mySQL

par SpipFactory A ce jour c’est une réussite ! Merci Merci Suske ... (14/02/2013) Posons la structure de départ soit 2 sites spip strictement identique même version( SPIP 3.0.5 [19905] ) , et les mêmes tables avec les mêmes champs ; l’un avec une bdd SQLite, l’autre avec une bdd mySQL. Le transfert ce fera du site 1 : sqLITE ; vers le site 2 mySQL - 1° Méthode. On réalise une sauvegarde SQLite du site 1 via la sauvegarde interne et on réimporte sur le site 2. -* Résultat : Table spip_abonnes absente Table spip_abonnes_lettres absente Table spip_abonnes_rubriques absente Table spip_abonnes_statistiques absente Table spip_articles, données manquantes Table spip_articles_lies absente Table spip_clics absente Table spip_desabonnes absente Table spip_documents, données manquantes Table spip_lettres absente Table spip_lettres_statistiques absente Table spip_mots, données manquantes Table spip_rubriques, données manquantes Table spip_rubriques_crontabs absente Table spip_shoutbox absente Table spip_syndic, données manquantes Table spip_themes absente Table spip_auteurs, données manquantes. et aucune table de remplie le site est désespérément vide - 2° Méthode Qui est pour moi la plus fiable on utilise le plugin sqlip_export de suske ; Pas trouvé comment on le lance avec l’aide de François L deplaine (merci) Pour lancer le téléchargement, le webmestre doit appeler : http://votre_site/spip.php?page=sqlite-mysql -# Je récupère un fichier mysql-dump -# Import via phpmyadmin dans le site 2 -* Résultat : Aucune données n’a été reçu en vue de l’importation. Aucun nom de fichier n’a été fourni, ou encore la taille du fichier a dépassé la limite permise par votre configuration de PHP. -# Import via bigdump dans site 2 -* Résultat : Bad Request Your browser sent a request that this server could not understand. Apache/2.2.17 (Win32) PHP/5.2.17 Server at * Port 80 - 3° Méthode -#Sauvegarde ma bdd via le dump de spip -# Ouvre avec sqlite manager -# Export Database -# Reimporte le SQL sur la base de phpmyadmin via bigdump -* Résultat : Bad Request Your browser sent a request that this server could not understand. Apache/2.2.17 (Win32) PHP/5.2.17 Server at * Port 80 - 4° Méthode idem a la troisième méthode sauf qu’on ouvre le fichier SQL et on remplace les doubles quotes (") par ce caractère : ` -* Résultat : Bad Request Your browser sent a request that this server could not understand. Apache/2.2.17 (Win32) PHP/5.2.17 Server at * Port 80 - 5°Méthode on me propose d’utiliser -* http://stackoverflow.com/questions/1067060/translating-perl-to-python/1070463#1070463 mais je voie pas comment faire ...., tous le monde n’est pas un dev donc si vous avez une piste, un tuto, une aide merci -6° Méthode Qui est pour moi la plus fiable -# on utilise le plugin sqlip_export de suske -# On ouvre le fichier mysql-dump avec un editeur de texte -# On Exécute une ou des requêtes sur la base via Phpmyadmin -* soit un DROP TABLE IF EXISTS `spip_syndic_articles` ;CREATE TABLE `spip_syndic_articles` ( jusque la prochaine table et on fait ça pour chaque table, j’ai éviter comme ça le Bad Request Your browser sent a request that this server could not understand. Apache/2.2.17 (Win32) PHP/5.2.17 Server at * Port 80 -* Résultat : echec pour une table spip_syndic_articles, que puis je faire ?? est elle importante on peut s’en passer ? Erreur MySQL a répondu : Documentation #2006 - MySQL server has gone away je constate également quelques erreurs d’encodage. - Concept d’utilisabilit ø au lieu et place de Concept d’utilisabilité -7° Méthode tenté d’utiliser le plugin « Migration » http://www.nursit.com/Le-plugin-migration-pour-SPIP on utilise que l’import - export des tables sur le site d’export -* La migration vers le site distant a été achevée avec sucés. sur le site d’import ça tourne , tourne ;) -* [preparer] on peut observer via phpmyadmin que seules les tables suivantes sont créées Structure spip_abonnes_clics Structure spip_articles_lettres Structure spip_auteurs Structure spip_depots_plugins Structure spip_meta Structure spip_pays Structure spip_resultats Structure spip_visites Structure spip_visites_articles -La Méthode qui Fonctionne Aprés un passage sur IRC Donc ça sera le plugin sqlip_export de suske Testé par lui même (Merci) sur son propre serveur avec ma base et bien ça fonctionne et donc c’est du coté du serveur qu’il me faut regarder.

Ci dessous la procédure pour passer un Spip SQLite en mySQL

-# Un site spip avec une base SQLite -# Un site spip avec une base mySQL -# Même plugins d’installé sur les deux sites spip -# Télécharger le plugin sqlip_export de suske -# Installer le plugin dans le site Spip possédant la bdd SQLite -# Lancer http://mon-site/spip.php?page=dumpmysql -# Récupérer le fichier mysql-dump.sql -# Ouvrir PhpMyadmin -# allez dans la bdd du site qui devra réceptionner dans l’onglet « Importer » -# choisir votre fichier mysql-dump.sql -# Attendre -# renommez le fichier config/connect.php et reprendre une install sur la base mysql -# et .............................. je vous dis quoi ;) ----

Ci-dessous le retour d’expérience de l’essai de passage d’un site spip sous SQLite a mySQL

par CloudGirofle En me basant sur la dernière solution de SpipFactory, voici ma méthode : -# Utilisation d’un seul site en sqllite3. -# Désactivation de tous les plugins (pas important pour moi - faire attention magré tout pour vous) -# Installation sous la version Sqllite3 du fameux plugin sqlip_export de suske. -# Export en local du fichier obtenu SAV.SQL. -# Par FTP renommer le /config/connect.php en lite3_connect.php (afin de le sauvegarder et simuler à spip une toute nouvelle installation). -# Relancer une installation de spip en version Mysql. -# Activer le plugin « sqlip_export ». -# Via phpmyAdmin importer notre export SAV.SQL. -# Et pour moi tout est OK... merci a tous ----

oct. 2016 - Sur un vieux site (spip 3.0.1) non mis à jour, avec une seule sauvegarde.sqlite de 2013 aussi, je n’arrivais pas à restaurer la base de données via l’admin de spip, 2 solutions :

par cilou Important : le début de la sauvegarde .sqlite commence par : ** This file contains an SQLite 2.1 database ** (en cause les extensions php de l’hébergeur) —> donc impossibilité d’utiliser tout les outils ou manips cités vu que sqlite2 et sqlite3 sont incompatibles (en erreur j’avais : pas de table trouvée ou fichier encrypté). 1re solution (donnée par un ami qui me cherchait une solution) : convertir le fichier sqlite2 en sqlite3 sous linux : -* https://sqlite.org/download.html -* sudo apt-get install sqlite (sert a installer le programme sqlite pour pouvoir exécuter la commande) -* sqlite base_old.sqlite .dump | sqlite3 base_new.sqlite La base base_new.sqlite fonctionne dans restaurer la base de l’admin spip 2e solution : -* En local, je me suis remis dans la configuration de 2013 (wampserver 2.2, php 5.3.10, mysql 5.5.20, apache 2.2.21) -* Php —> php extensions : j’ai décoché php_pdo_sqlite et coché php_sqlite -* j’ai lancé la restauration de ma base sqlite2 et là, miracle, j’ai récupéré toutes les données -* Php —> php extensions : j’ai remis comme c’était à l’origine -* Sauvegarde de la base —> le début du fichier est devenue : SQLite format 3 -* Test de restauration de cette nouvelle base : ok Peut être qu’avec un wampserver plus récent ça marche aussi... l’important est, je crois, de décocher les extensions qui font appel à du sqlite3. Voila, si ça peut peut être vous éviter 3 jours de stress ;)