SQLiteManager mais je n'ai pas testé encore.

Sur le fond (lourdeur souvent inutile de MySQL et pris en otage par MySQL) je suis d'accord avec jehanon. Par contre, je pense que la solution n'est certainement pas dans XML mais dans SQLite. Et SQLite sera dispo pour la 2.1.

ddtddt, déplacer une base MySQL c'est compliqué. C'est compliqué quand tu sais comment ça se passe avec une base de données sans serveur (comme SQLite ou BerkeleyDB) où il suffit de copier 1 fichier ailleurs.

grum, à mon avis si on ne répond pas à tes questions, c'est parce qu'elles contiennent la réponse : on ne peut pas remplacer MySQL par XML de manière transparente. Pas dans un temps de développement raisonnable.

J'ajoute que l'actualité de MySQL nous encourage à nous ouvrir à des alternatives. Je fais référence au rachat de Sun et plus préoccupant le rachat par Oracle en cours d'homologation au niveau européen. En ce qui me concerne, la priorité, c'est SQLite. (pour nicolas, c'est PostgreSQL)

SQLite  est sans doute une très bonne idée, on a souvent qualifiée  MS Access de jouet mais c'est bien pratique d'avoir un fichier a bouger et Access était suffisant dans beaucoup de cas
si en plus ce n'est pas du microsoft c'est encore mieux

j'ignore si SQLite est valable pour des centaines d'utilisateurs  et 100 000 images, mais très certainement pour des sites plus légers, et avoir ce choix me semble un plus

Dernière modification par jehanon (2009-12-28 21:56:48)

VDigital a écrit:

A mon avis, cela n'engage que moi: SQLite ne devrait pas convenir à Piwigo.

Nous en reparlerons. Des tests en profondeur devront être réalisés avec des accès concurrents, l'historique actif, et une resynchro complète des images.
Je pense que beaucoup devraient être assez déçus et que Nicolas a mille fois raison.
L'avenir le dira, mais XML ce n'est absolument pas pour Piwigo.

On verra bien :-) J'attends pas mal de SQLite pour être franc ! Mon objectif, c'est de réduire l'empreinte mémoire et le nombre total de fichiers sur mon système (je fais référence à piwigo.com).

Je ferai évidemment des tests avec accès multiples et concurrents en SQLite Vs MySQL Vs PostgreSQL et on pourra discuter des avantages et inconvénients avec des chiffres à l'appui.

Ce qui me fait un peu "peur" avec SQLite, ce n'est pas la performance, c'est la robustesse. MySQL, l'expérience m'a montré que c'était presque incassable. SQLite, je n'ai pas le recul suffisant pour en parler sereinement.

plg a écrit:

J'ajoute que l'actualité de MySQL nous encourage à nous ouvrir à des alternatives. Je fais référence au rachat de Sun et plus préoccupant le rachat par Oracle en cours d'homologation au niveau européen. En ce qui me concerne, la priorité, c'est SQLite. (pour nicolas, c'est PostgreSQL)

C'est limite HS mais peux-tu éclairer ma lanterne sur ce qui te donne des frissons ?
:-)

Dis comme ça je comprends bien la nécessité d'avoir plusieurs cordes à son arc.
Merci Vincent.

Probablement, mais attention aux légions d'avocats qu'un Oracle est capable de prévoir.

Non tu ne titilles pas, je crois qu'on t'a expliqué qu'on ne gère pas une galerie pour un photographe qui propose un petit nombre de clichés, mais une galerie qui s'adresse au plus grand nombre et donc à des usages extrêmes.

PostgreSQL (http://www.postgresql.org/) est déjà dispo dans la trunk pour info grâce à Nicolas.