Salut la liste,
j’ai essayé spip3 dans une config sans sqlite3, la sauvegarde plante car elle ne propose que le format .sqlite
Pourquoi ne pas générer (à moins que ce soit prévu) un fichier .sql pour MySQL ?
De plus, je n’ai pas trouvé comment importer une sauvegarde de spip2.1 sous spip3
Désolé si ce bug est connu et archi connu, je manque de temps (et de connexion web) pour vérifier…
Cette version alpha semble bien prometteuse en tt cas !!
Hello,
Salut la liste,
j'ai essayé spip3 dans une config sans sqlite3, la sauvegarde plante car elle ne propose que le format .sqlite
oui, et il n'y aura que ça d'intégré. SQlite permet de générer *un* fichier de sauvegarde facilement déplaçable,
et le format SQL permet de gérer proprement la copie de base à base.
Le format dump xml existant précédemment avait plein de défauts, et une fiabilité très aléatoire.
Pourquoi ne pas générer (à moins que ce soit prévu) un fichier .sql pour MySQL ?
cf ci-dessus : cela ne permet pas de générer un fichier de sauvegarde déplaçable
De plus, je n'ai pas trouvé comment importer une sauvegarde de spip2.1 sous spip3
Même si les versions précédentes avaient une robustesse améliorée vis à vis de cela,
l'absence du stockage du format de base dans la sauvegarde ne permettait pas de garantir l'interopérabilité de ce type.
La sauvegarde au format SQLite le permet au contraire, puisque le schéma de la base initiale est aussi sauvegardé et réutilisé en cas de restauration.
Il y a un plugin sur la zone qui reprend la fonctionnalité dump.xml antérieure, pour compatibilité.
Cédric
je veux bien que SPIP génère une base compatible avec sQlite, mais ce que je disais c’est que mon hébergement n’avait PAS sqlite.
Donc la sauvegarde plantait.
Que proposera SPIP dans un tel scénario ?
2011/7/12 cedric.morin@yterium.com <cedric.morin@yterium.com>
Dans les (normalement rares) cas où PHP ne sait pas gérer SQLite, tu peux toujours mettre l'ancien système de sauvegarde qui est dans un plugin à part (donc améliorable quand même pour ceux qui continuent de l'utiliser).
je veux bien que SPIP génère une base compatible avec sQlite, mais ce
que je disais c'est que mon hébergement n'avait PAS sqlite.
Donc la sauvegarde plantait.
ça ne devrait pas planter, mais refuser de démarrer. Un problème de détection sans doute ?
Que proposera SPIP dans un tel scénario ?
Rien. C'est un choix assumé.
Si ton hébergement n'a pas SQLite, et ne te donne pas non plus d'outil pour faire une sauvegarde de tes bases mysql, c'est en effet problématique.
Mais a peine plus que la situation antérieure ou tu croyais avoir une sauvegarde qui n'en était pas vraiment une non plus.
Dans les (normalement rares) cas où PHP ne sait pas gérer SQLite, tu peux toujours mettre l'ancien système de sauvegarde qui est dans un plugin à part (donc améliorable quand même pour ceux qui continuent de l'utiliser).
L'ancien format dump.xml n'a jamais constitué une sauvegarde fiable, et je ne pense pas qu'on puisse dire qu'il s'agisse réellement d'un fallback à ce titre.
Il avait été pensé et réalisé comme un outil de migration, pour déplacer sa base d'un serveur sur un autre.
Pour ce besoin, le plugin migration existe. Et le remplit bien mieux et simplement.
(Il peut aussi être alternativement utilisé comme outil de backup en réalisant un miroir du site sur un autre.)
Cédric
Merci pour ces précisions.
2011/7/18 cedric.morin@yterium.com <cedric.morin@yterium.com>