Hello,
sqlite est structurellement plus lent que mysql vu que SPIP n’utilise pas les transactions.
C’est donc pénalisant de proposer sqlite comme format de base par défaut - sans compter les problèmes de mise à jour, de conversion, de compatibilité avec l’hébergeur, etc.
Je propose qu’on discute avant la 3.0.6 que l’ordre des base redevienne celui de la version 2.1.19
.Gilles
Hello,
sqlite est structurellement plus lent que mysql
oui et ? La vrai question est : est-ce que SQLite est assez performant pour faire fonctionner un site SPIP.
Tant qu'on parle de sites dont le nombre de visites est inférieur à 10000/jour, SQLite ne pose aucun problème de performance pour SPIP.
Pour un traffic supérieur, il peut être utile de se poser la question, mais je pense que ceux qui gèrent ce type de traffic savent exactement de quoi il en retourne.
vu que SPIP n'utilise pas les transactions.
Faux : certaines fonctions comme sql_insertq_multi utilisent les transactions.
C'est donc pénalisant de proposer sqlite comme format de base par défaut -
Oui donc comme les postulats de départs qui t'amènent à cette conclusion sont erronées, je ne peux adhérer à cette conclusion.
sans compter les problèmes de mise à jour,
Quels problèmes de mise à jour ?
de conversion,
Oui il y a un soucis identifié pour le retour de SQLite vers Mysql. L'opération n'est pas faisable simplement, il faut améliorer cela.
de compatibilité avec l'hébergeur, etc.
Ben si l'hebergeur ne propose pas SQLite, l'installation se fait en MySQL, je ne vois pas le problème.
Je propose qu'on discute avant la 3.0.6 que l'ordre des base redevienne celui de la version 2.1.19
Oui, on peut en discuter, mais sur la base de bons arguments.
Il ne faudrait pas oublier de dire que cela simplifie l'installation (observe un débutant devant la question du login/mot de passe mysql), et cela rend aussi le site portable : un simple copie/colle de tout le dossier suffit.
Cédric
Oui, voilà, la facilité de transfert, ça c'est un plus énorme... Mais
qui repose la question du passage sqlite->mysql pour ceux qui veulent.
Que l'on peut résoudre par ailleurs, donc amha pas de besoin de changer
ça tout de suite pour mettre mysql par défaut.
Après, c'est bien de se poser la question quand même. Mais revenir à
MySQL en 3.1 ou 4.0, pourquoi pas s'il y a de super raisons. En
attendant, MySQL est pas interdit hein ?!
2013/3/9 Cédric Morin <cedric.morin@yterium.com>
Hello,
sqlite est structurellement plus lent que mysql
oui et ? La vrai question est : est-ce que SQLite est assez performant pour faire fonctionner un site SPIP.
Tant qu’on parle de sites dont le nombre de visites est inférieur à 10000/jour, SQLite ne pose aucun problème de performance pour SPIP.
Je n’en suis pas convaincu.
Sur quels tests te bases-tu ? Il y a pleins d’éléments qui peuvent pénaliser sqlite : le nombre d’accès concurrents, la taille de la bases, les requêtes non optimisée qui ne permettent pas l’usage des index, les jointures, etc…
cf. http://blog.idleman.fr/?p=1371
http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
Pour un traffic supérieur, il peut être utile de se poser la question, mais je pense que ceux qui gèrent ce type de traffic savent exactement de quoi il en retourne.
Là aussi, je n’en suis pas convaincu.
D’ailleurs, une question que je me suis toujours posé, c’est comment un utilisateur peut réagir face à une montée en charge et un ralentissement de son site ? Sous mysql, on peut optimiser le configuration du serveur, lui affecter plein de ressources, faire du load-balancing, du cache en mémoire, etc. (il y a plein de tutoriels là dessus). Mais sqlite ? je n’ai rien trouvé.
La plupart des utilisateurs sont sur un environnement mutualisé.
SQlite est basé sur des accès disque uniquement. Sans entrer dans des notions de filers mal dimensionnés et de stockage de fichiers sur des disques lents, cette ressources est la plus difficilement partageable sur un serveur. Donc un utilisateur est beaucoup plus sensible à des ralentissements liés à d’autres utilisateurs.
MySql fait aussi beaucoup d’accès disque (et consomme beaucoup de mémoire). Mais les bases de données sont souvent stockées dan des espaces dédiés avec des ressources qui sont un peu mieux optimisées (disques rapides, plus de mémoire, cpu rapide, etc.)
vu que SPIP n’utilise pas les transactions.
Faux : certaines fonctions comme sql_insertq_multi utilisent les transactions.
Je parle de la majorité des requêtes.
il y a moins d’appels dans le code de SPIP et de ses plugins (question de culture ?)
sans compter les problèmes de mise à jour,
Quels problèmes de mise à jour ?
C’est pas simple d’avoir un site en 2.1.19 sous mysql et de le passer en 3.0.x en sqlite
Beaucoup d’utilisateurs ne comprennent pas la différence entre les différents formats de base de données et prennent donc celui par défaut.
Le fait d’avoir changé ce choix par défaut est plus perturbant qu’autre chose.
Il y a des points bénéfiques dans certains cas à choisir sqlite.
Mais il faut que ce soit un choix de l’utilisateur.
de compatibilité avec l’hébergeur, etc.
Ben si l’hebergeur ne propose pas SQLite, l’installation se fait en MySQL, je ne vois pas le problème.
Je pensais surtout à la structure liée à la mutualisation (abordée ci-dessus) - et à des hébergeur qui ont de très vieilles versions de sqlite (cf. Free.fr)
Tous les hébergeurs ont des interfaces de gestion à MySQL. Pour modifier des éléments dans sqlite il faut utiliser des interfaces nettement moins pratiques à installer soit-même (de ce côté c’est une vrai régression)
Je propose qu’on discute avant la 3.0.6 que l’ordre des base redevienne celui de la version 2.1.19
Oui, on peut en discuter, mais sur la base de bons arguments.
Il ne faudrait pas oublier de dire que cela simplifie l’installation (observe un débutant devant la question du login/mot de passe mysql), et cela rend aussi le site portable : un simple copie/colle de tout le dossier suffit.
Certes on gagne en portabilité et en facilité d’installation.
Mais qui va vraiment utiliser souvent cette portabilité ? A part au moment où on bascule le site d’une version locale à une version en ligne (ce que tout le monde ne fait pas), je ne vois pas.
L’installation sans paramètre est un leurre : ils sont fournis par l’hébergeur en même temps que les paramètres d’accès ftp. Donc l’utilisateur les a forcément sous la main.
Ces deux points interviennent à un instant précis dans la vie d’un site Internet, alors qu’un défaut de performance va impacter toute la suite. C’est là dessus qu’il faut se concentrer. Si on peut avoir les deux, tant mieux.
Effectivement, la réflexion peut attendre la 3.1, car pour l’étayer il faudrait des tests :
perso je prévois de faire des tests sur des sites réels installés sous les deux bases.
Au delà du nombre de visites, je pense que la taille des données compte. Je vais travailler là dessus. Ce qui permettra de comparer comment un site évolue dans le temps avec 100, 200 ou 1000 articles
J’ai un hébergement des test sur les pages persos de Free, je vais essayer de trouver des codes d’accès à du mutualisé OVH sur lequel on a pas mal de remonté de problème - ça permettra de comparer avec un environnement isolé de type dédié
2013/3/9 Suske
Un élément qui vient de me parvenir :
l’utilisation de sqlite est interdite “a priori” chez Free.
J’attends une réponse de la part de l’administrateur sur le pourquoi du comment, mais je doute qu’il réponde, comme il ne l’a pas fait pour l’interdiction des stats.
C’est plus une info qu’un argument en fait.
Avis à ceux qui sont sur les pages perso de Free : passez chez un vrai hébergeur calibré pour SPIP (de type Nursit), sinon vous risquez de trouver votre compte bloqué sans explication.
Côté dev, je pense qu’on peut imposer pour les prochaines versions de SPIP que ce soit sqlite3 et basta
Bonjour,
Je rapporte aussi qq.elements d'expérience... dans le meme sens !
Un élément qui vient de me parvenir :
l'utilisation de sqlite est interdite "a priori" chez Free.
<Accueil - Les Pages Perso Chez Free;
Et sur un mutualisé OVH, j'ai vu l'installation SQLIte
(secretement) implantée dans un MySQL
mais sur un hebergement inaccessible au PhpMyAdmin du Manager
et il m'a fallu attendre une reponse d'OVH pour finir par comprendre...
(heureusement que Suske m' fait decouvrir Adminer).
J'attends une réponse de la part de l'administrateur sur le pourquoi du
comment, mais je doute qu'il réponde, comme il ne l'a pas fait pour
l'interdiction des stats.Avis à ceux qui sont sur les pages perso de Free : passez chez un vrai
hébergeur calibré pour SPIP (de type Nursit), sinon vous risquez de
trouver votre compte bloqué sans explication.
Info FREE (et parfois OVH) pas assez répétée (mais "pas de pub" 
Côté dev, je pense qu'on peut imposer pour les prochaines versions de
SPIP que ce soit sqlite3 et basta
Je ne peux absolument pas comprendre ce 'diktat' alors
que l'un des atouts de SPIP est justement son inter-opérabilité
multi-bases qui permet d'envisager des portails intranet
simplemement connectés aux Bases du Système d'Information.
Comment comprendre ce "je pense", sans arguments (dev ET user)
à part peut-etre l'amélioration des /ecrire/base/... alors que
la gestion multi-base etait un argument facilitateur de l'API SPIP ?
---
2013/3/9 Cédric Morin <cedric.morin@yterium.com
<mailto:cedric.morin@yterium.com>>> Hello,
>
> sqlite est structurellement plus lent que mysqloui et ? La vrai question est : est-ce que SQLite est assez
performant pour faire fonctionner un site SPIP.
Tant qu'on parle de sites dont le nombre de visites est inférieur à
10000/jour, SQLite ne pose aucun problème de performance pour SPIP.
Pour un traffic supérieur, il peut être utile de se poser la
question, mais je pense que ceux qui gèrent ce type de traffic
savent exactement de quoi il en retourne.> vu que SPIP n'utilise pas les transactions.
Faux : certaines fonctions comme sql_insertq_multi utilisent les
transactions.> C'est donc pénalisant de proposer sqlite comme format de base par
défaut -Oui donc comme les postulats de départs qui t'amènent à cette
conclusion sont erronées, je ne peux adhérer à cette conclusion.> sans compter les problèmes de mise à jour,
Quels problèmes de mise à jour ?
> de conversion,
Oui il y a un soucis identifié pour le retour de SQLite vers Mysql.
L'opération n'est pas faisable simplement, il faut améliorer cela.
Quel sens de la litote, si je puis me permettre...
> de compatibilité avec l'hébergeur, etc.
Ben si l'hebergeur ne propose pas SQLite, l'installation se fait en
MySQL, je ne vois pas le problème.>
> Je propose qu'on discute avant la 3.0.6 que l'ordre des base
redevienne celui de la version 2.1.19Oui, on peut en discuter, mais sur la base de bons arguments.
Il ne faudrait pas oublier de dire que cela simplifie l'installation
(observe un débutant devant la question du login/mot de passe
mysql), et cela rend aussi le site portable : un simple copie/colle
de tout le dossier suffit.
Cela simplifie (peut-etre) le travail du debutant UNE FOIS
mais dès qu'il a un quelconque probleme, et qu'on lui dit
"regarde ta base" (sous entendu, avec phpMyAdmin)
les problemes commencent......
Le seul autre cas de simplification est l'opportunité de créer
un portage local aussi en SQLite, avec les memes difficultes
pour rajouter au Wamp/Mamp/EasyPhp auto-installé
une gestion SQLite.....qui n'est que peu expliquée !
Donc +1 à MySQL en tete (et quid de PG ? )
Le support de PG est buggué et pas du tout utilisable en production. Je pense qu’il ne devrait même pas être proposé en l’état, mais ça n’engage que moi.
Cédric
Petite précision car j’étais énervé
2013/3/10 YannX/SPIP <yannx.spip@hotmail.fr>
Côté dev, je pense qu’on peut imposer pour les prochaines versions de
SPIP que ce soit sqlite3 et bastaJe ne peux absolument pas comprendre ce ‹ diktat › alors
que l’un des atouts de SPIP est justement son inter-opérabilité
multi-bases qui permet d’envisager des portails intranet
simplemement connectés aux Bases du Système d’Information.
Je parle juste de compatibilité.
Actuellement sqlite est trop vieux sur les pages perso de Fr… pour que ça fonctionne sans un patch qui lui est presque dédié. De toute manière le problème sera réglé si c’est annoncé que sqlite est une raison de blocage sur leur plateforme.
On n’aurait plus qu’à garder le test actuel sqlite 2 / sqlite 3. Mais ce type de test est-il encore pertinent ? Existe-t-il une plateforme sur laquelle seul sqlite2 est installé ?
C’est comme l’abandon de la compatibilité avec PHP4 : cela a simplifié l’écriture du code et était bénéfique.
L’abandon d’une compatibilité avec sqlite2 n’a de sens que si on y gagne en performance, bien sur.
Et je précise qu’un tel changement est une modification majeure qui ne peut se faire que lors d’un passage à la version 3.1 - Donc pas tout de suite.
D'après mes souvenirs, c'est le meme souci avec la version d'Oracle
développée par ESJ
http://zone.spip.org/trac/spip-zone/browser/dev/oracle
(et j'avais etudié un M$SQL de meme... travail inachevé = hors-zone
oui, qd on n'a que cela sous la main !!).
Si on proposait ces plugins "systèmes"
(en en attendant d'autres SGBD, peut-etre PDO ?)
comment faudrait-il organiser l'installation pour faciliter :
- le choix alternatif du pilote de SGBD à l'installation
(sans devoir créer le connect.php à la main)
- le téléchargement d'installation préalable du SGBD
avant d'avoir l'espace privé accessible ?
- et proposer leur installation en base de connectivité annexe ?
PS à cette occasion je relis
http://zone.spip.org/trac/spip-zone/browser/dev/dump_xml
(non modifié depuis 7 ans)
http://zone.spip.org/trac/spip-zone/browser/core/plugins/dump
Il est plus lent oui parfois, mais pas pour la raison que tu dis 
Il pèche surtout en écriture. Et oui, on est d'accord, il y a des améliorations à apporter pour pouvoir gérer des importations de dump d'un spip/sqlite dans un spip/mysql. Mais c'est pas simple !
Bon, mais c'est pas pour ça que j'interviens.
J'ai en quelques commits (je rigole) fait un portage à tester pour utiliser mysqli_* au lieu de mysql_* qui va disparaître en PHP 5.5.
Là donc.
http://core.spip.org/projects/spip/repository/revisions/20265
Je m'y suis repris à plein de fois, mais en fait je crois que mon premier commit était bon http://core.spip.org/projects/spip/repository/revisions/20261 et que c'est juste RedMine qui a pas fait le diff que j'attendais : un diff de ce qui a été modifié par rapport à l'origine de la copie. Du coup j'ai cru que ça avait fait un add perdant l'historique, mais pas du tout. Bref, redmine m'a eu sur ce coup là.
Donc, si tu veux le tester en même temps que tu testes d'autres choses, ce sera chouette. Il semble que mysqli_* est légèrement plus rapide que mysql_*.
Voilou
Ceci testé, on pourra basculer dessus ("mysql" = mysqli à l'installation, et pour les anciens connecteurs), copier mysqli.php en mysql.php et mysql.php en mysql_old.php (ou le virer). Enfin à réfléchir. Là pour l'instant, c'est pour tester.
MM.
cool, je vais tester.
J’ai un nouveau jouet, merci Marcimat !
2013/3/10 Matthieu Marcillaud <marcimat@rezo.net>
Je suis pour.
Je trouve que SPIP se complexifie, mais peut-être est-ce normal (vu tout les trucs biens) et voulu (pourquoi simplifier)
j'ai le sentiment que les utilisateurs ne peuvent plus apprendre facilement sans passer par des surcouches (Bootstrap, Zcore, Sqlite …)
Par exemple dans un 1er niveau Sqlite c'est bien, quand on ne connait rien et qu'on ne veut rien faire d'autre que cliquer. Mais quand on veut apprendre c'est incompréhensible, alors qu'avec phpmyadmin on comprend rapidement l'organisation des tables.
A moins qu'il y ait un outil que j'ignore pour lire le fichier sqlite.
Je dis ça un peu au désespoir de ne pas être entendu tant j'ai l'impression que SPIP est passé à la phase soit débutant soit expert, et que son apprentissage s'en trouve amha fortement réduit.
mes 2 sous
Oui : http://www.adminer.org/
Pat, qui confirme aussi la croissante complexité de SPIP.
Bonjour,
Moi je trouve qu'il se simplifie.
Les liaisons entre informations (objets) sont bien plus homogènes, l'interface SPip3 bien plus cohérente, les plugins indispensables présents d'origine, ...
Peut-être certains trouvent-ils ça compliqué parce que la transition v2->v3 entraine la remise en question et l'accumulation d'anciens acquis.
La fabrique est un bijou.
Aujourd'hui j'aimerais qq éclaircissements sur SPIP-r dont je vois passer des choses.
En 10 lignes, objectif, avantages et inconvenients par rapport à l'existant. Peut-être un article en préparation sur Contrib accessible avant sa publication ?
Je suis pour.
Je trouve que SPIP se complexifie, mais peut-être est-ce normal (vu tout
les trucs biens) et voulu (pourquoi simplifier)
j'ai le sentiment que les utilisateurs ne peuvent plus apprendre
facilement sans passer par des surcouches (Bootstrap, Zcore, Sqlite …)
Par exemple dans un 1er niveau Sqlite c'est bien, quand on ne connait
rien et qu'on ne veut rien faire d'autre que cliquer. Mais quand on veut
apprendre c'est incompréhensible, alors qu'avec phpmyadmin on comprend
rapidement l'organisation des tables.
A moins qu'il y ait un outil que j'ignore pour lire le fichier sqlite.
Bonjour,
Peux-tu essayer d'être plus précise lorsque tu dis «se complexifie» ? Peux-tu donner des/d'autres exemples concrets de ce qui s'est complexifié dans SPIP ? Par exemple tu parles de bootstrap, mais au dernières nouvelles ce plugin n'est pas encore finalisé (ni documenté)…
Pour ma part je crois que c'est surtout ce qu'on fait avec et ce qu'on lui demande qui s'est modifié et complexifié.
Pour revenir à SQLite, il y a en local SQLite Manager dans Firefox que j'utilise souvent. Tu peux monter dans ubuntu le dossier distant en FTP ou SSH pour y accéder aussi via Firefox, ou comme l'a dit quelqu'un utiliser Adminer en ligne ? Je crois que Suske a fait un plugin pour ça il me semble.
Et est-ce que c'est se complexifier d'utiliser SQLite ? Demande de faire une sauvegarde correcte de ta base MySQL : il faut mysqldump en ligne de commande ou passer par phpmyadmin ou utiliser le plugin Sauvauto (mais tu ne pourras pas restaurer une sauvegarde, en ligne, de plus de 8Mo - selon la tolérance de PHP en upload), sinon celui de SPIP (dump) en sqlite (mais il te faut un SPIP pour le remettre chez toi).
En sqlite : tu prends ton fichier .sqlite, tu le copies, tu as ta sauvegarde. Pour SQLite, du coup, il me semble que c'est surtout un changement d'habitude avant tout. Il est vraiment difficile de faire plus simple que SQLite pour une base de données. Mais oui, après les outils sont différents pour les gérer. Peut être qu'il faut ajouter Adminer ou autre directement à SPIP ? Et oui, SQLite à des contraintes, tout comme MySQL, et évidemment, ce sont pas les mêmes, ça serait trop simple 
Je dis ça un peu au désespoir de ne pas être entendu tant j'ai
l'impression que SPIP est passé à la phase soit débutant soit expert, et
que son apprentissage s'en trouve amha fortement réduit.
Que faudrait-il pour changer ce fait (ou cette impression) ?
MM.
Hello,
Un tableau de bord peut-être listant toutes les fonctions automatiquement reconnues ? Celles qui pourraient exister mais qui ne sont pas trouvées ? Les fonction surchargées ? Les squelettes surchargés ? Les noisettes et modèles disponibles ? Lister au clair toutes les autorisations ? Avec leurs priorités ? Lister les objets disponibles ? Avec toutes les caractéristiques ? Les pipelines ? Les jointures ? Les hiérarchies ? etc, etc, etc, etc, etc, etc !
Bref, des interfaces supplémentaires histoire de clarifier ce que SPIP fait très bien dans son code, mais pas dans la tête des utilisateurs. Programmer en assembleur ("comme disait quelqu'un...") c'est excitant, mais ce n'est pas trop l'objet ici.
Pour mon cas perso, je suis obligé de lire le code pour me tenir au courant et voir que y en a de partout, avec toutes les interrogations qui vont avec...
Je crois que c'est une très bonne chose tout ça, merci pour tout ce boulot. Bravo pour la fabrique, qui permet de se rendre compte à tel point SPIP a avancé dans sa gestion des objets. Mais de mon petit point de vue, plus vous avancez, plus c'est loin d'être simple à appréhender.
Pat
Je suis pour.
Je trouve que SPIP se complexifie, mais peut-être est-ce normal (vu tout
les trucs biens) et voulu (pourquoi simplifier)
j'ai le sentiment que les utilisateurs ne peuvent plus apprendre
facilement sans passer par des surcouches (Bootstrap, Zcore, Sqlite …)
Par exemple dans un 1er niveau Sqlite c'est bien, quand on ne connait
rien et qu'on ne veut rien faire d'autre que cliquer. Mais quand on veut
apprendre c'est incompréhensible, alors qu'avec phpmyadmin on comprend
rapidement l'organisation des tables.
A moins qu'il y ait un outil que j'ignore pour lire le fichier sqlite.Bonjour,
Peux-tu essayer d'être plus précise lorsque tu dis «se complexifie» ? Peux-tu donner des/d'autres exemples concrets de ce qui s'est complexifié dans SPIP ? Par exemple tu parles de bootstrap, mais au dernières nouvelles ce plugin n'est pas encore finalisé (ni documenté)…
Ah, d'abord, une petite mise au point, j'essaie de ne pas _trop_ parler de mon utilisation personnelle de SPIP, même si ma réflexion transite évidemment par mon propre usage, mais je ne suis pas représentative des utilisatrices (.eurs) de SPIP, j'essaie juste d'imaginer!
J'aimerais soulever 2 points:
- Quid de l'utilisateur lambda curieux de découvrir comment ça marche et d'apprendre
- Comment prendre en compte (si possible) la nécessité de réduire le poids du programme, son calcul et son bilan énergétique (surtout quand c'est pour un petit site)
Aujourd'hui, ce n'est pas qu'avec SPIP que l'on va utiliser des surcouches avec des frameworks comme Bootstrap.
Je sais bien que Less et Html5 c'est super, mais on est d'accord que ça fait beaucoup quand c'est pour débuter et apprendre. Même si c'est abouti et documenté!
Pour ma part je crois que c'est surtout ce qu'on fait avec et ce qu'on lui demande qui s'est modifié et complexifié.
Boh, un site internet, ça reste la même chose quand même depuis quelques années, ça a même tendance à se standardiser (ce qui est bien pour l'accessibilité et ceux.celles qui développent aussi!) mais j'entends ce que tu dis.
Pour revenir à SQLite, il y a en local SQLite Manager dans Firefox que j'utilise souvent. Tu peux monter dans ubuntu le dossier distant en FTP ou SSH pour y accéder aussi via Firefox, ou comme l'a dit quelqu'un utiliser Adminer en ligne ? Je crois que Suske a fait un plugin pour ça il me semble.
Je viens de tester SQLite Manager, tout de suite, ça fait pas comme je voudrais de suite, donc faut que je rtfm, mais faut aimer apprendre (encore et toujours!). Peut-être ce sont mes habitudes, mais je ne crois pas, tout concourt à changer rapidement les choses et à les remplacer par des toujours mieux, c'est aussi ça la technocratie, parce qu'il faut partager la connaissance et donc le pouvoir de commander à la machine, et ce depuis toujours, que SPIP en soit atteint est un peu normal aussi.
Et est-ce que c'est se complexifier d'utiliser SQLite ? Demande de faire une sauvegarde correcte de ta base MySQL : il faut mysqldump en ligne de commande ou passer par phpmyadmin
Oui, ça complexifie d'utiliser sqlite. Et phpmyadmin c'est plutot simple non? même la ligne de commande pour mysql c'est pas très dur. Et quand je fais des tests je tape direct en SQL.
ou utiliser le plugin Sauvauto (mais tu ne pourras pas restaurer une sauvegarde, en ligne, de plus de 8Mo - selon la tolérance de PHP en upload)
Au dessus de 8Mo, on peut considérer que c'est un site important quand même, et je suis d'accord que dans ces cas là, faut savoir gérer un peu plus.
sinon celui de SPIP (dump) en sqlite (mais il te faut un SPIP pour le remettre chez toi).
Mais le nombre de fois ou la restauration sqlite a foiré je compte même plus, et je ne saurais trouver là ou ça coinçait parce que la personne qui me passait sa sauvegarde avait peut-être un plugin foireux, en tout cas je me retrouvais auteur à la place d'un autre etc. Perte de temps, ennervement, je choisirais pas sqlite de suite.
En sqlite : tu prends ton fichier .sqlite, tu le copies, tu as ta sauvegarde. Pour SQLite, du coup, il me semble que c'est surtout un changement d'habitude avant tout. Il est vraiment difficile de faire plus simple que SQLite pour une base de données. Mais oui, après les outils sont différents pour les gérer. Peut être qu'il faut ajouter Adminer ou autre directement à SPIP ? Et oui, SQLite à des contraintes, tout comme MySQL, et évidemment, ce sont pas les mêmes, ça serait trop simple
Ah, bon, tu vois donc! la courbe d'apprentissage, oui, c'est rigolo, mais y'a pas que ça dans la vie!
Je dis ça un peu au désespoir de ne pas être entendu tant j'ai
l'impression que SPIP est passé à la phase soit débutant soit expert, et
que son apprentissage s'en trouve amha fortement réduit.Que faudrait-il pour changer ce fait (ou cette impression) ?
Merci, je reconnais bien là ton exigence à aider les autres
En fait, chaque fois qu'il y a une surcouche, on ne sait plus ce qui est important quand on veut modifier un tant soit peu. Bientôt on pourra effectivement choisir et glisser des blocs, mettre leur contenu dedans, les agencer dans la page, choisir le style, mais on aura (il me semble) perdu la capacité de comprendre comment ça marche, seulement certaines personnes seront capables de programmer. Et même notre propre obsolescence sera programmée, parce qu'il y a toujours mieux et que pour suivre il faudrait rester river à son ordi.
J'ai le sentiment qu'il faudrait pour aider à la compréhension pour tou.te.s, une organisation de fichier + simple (un dossier de dist avec squelettes, plugins etc dedans) et un set de plugins à se télécharger en fonction de son projet.
Partant du principe que l'utilisateur (.trice) lambda veut, la plupart du temps, un outil pour faire un site précis
- une asso, une galerie d'images, un site vitrine, un blog… lui proposer un pack simple qu'il peut "enrichir" ensuite.
Faire "monter" les nouveautés en 2em option, genre garder mysql en 1er et sqlite en second.
Mais c'est un ressenti perso.
Il a écrit un tutoriel :
http://contrib.spip.net/Editer-votre-base-SQLite-en-ligne-avec-Adminer
L'idéal serait un plugin qui installe adminer, configure directement la
connexion à la base et en même temps authentifie l'utilisateur pour que
seuls les webmasters y ait accès (et éviter ainsi une faille de sécu) et
enfin intègre l'outil dans l'espace privé.
A priori, il semble que c'est possible. Mais j'avoue ne pas avoir eu le
temps de m'y pencher plus en détail.
Joseph
Hello,
2013/3/11 touti <toutati@free.fr>
Je suis pour.
Je trouve que SPIP se complexifie, mais peut-être est-ce normal (vu tout les trucs biens) et voulu (pourquoi simplifier)
A mon avis c’est plus un ressenti qu’une réalité :
techniquement SPIP a évolué dans le bon sens, l’API est devenue mature et les concepts se sont homogénéisés.
Mais la documentation la plus structurée et pédagogique est actuellement aussi la plus technique.
La documentation sur les concepts simples de SPIP, ce qui en fait la base et est suffisant pour faire 80% des sites, est moins bonne.
Il suffit donc de faire mieux que programmer.spip.net pour revaloriser la simplicité initiale de SPIP
j’ai le sentiment que les utilisateurs ne peuvent plus apprendre facilement sans passer par des surcouches (Bootstrap, Zcore, Sqlite …)
SPIP va plus loin maintenant qu’avant et fait appel à des concepts plus abstraits que dans d’anciennes versions.
C’est pour ça que certains trouvent que SPIP sous 1.8.2 est « plus simple » car on n’a pas de #ARRAY, #SET, itérateurs, etc… - mais uniquement des éléments « concrets ».
Mais on peut toujours faire un site exactement comme sous d’anciennes versions