GruiicK a écrit :
Georges Khaznadar wrote:

Bonjour Deelight,

Une autre solution bien meilleure serait que les photos soient stockées
dans la base de données (comme blobs). Les avantages seraient qu'un dump
de la base de donnée serait suffisant pour restaurer tout le service,
et d'autre part qu'en cas de "jeu" avec le paquet, puis suppression du
paquet, puis réinstallation du paquet, on ne risque pas de voir
persister des photos dont le nom de fichier interfère avec la nouvelle
numérotation des adhérents dans le paquet réinstallé.

 Je suis aussi assez de cet avis : Les photos dans la bdd. Pour avoir
 fait plusieurs migrations Galette, j'ai toujours eu des sueurs froides
 à ce moment là.

C'est tout à fait envisageable, mais à ce moment là, soit on utilise gd pour redimensionner les images, soit on impose à l'utilisateur une taille maxi. Dans la version actuelle, on accepte les images de grande taille, mais dans une bdd, il faudrait éviter. Mais je trouve que c'est une bonne idée.

 Mais quand je vois les changements qui se profilent pour galette-0.63,
 j'ai les chocottes. J'ai pas vraiment envie de me re-saisir plus 200
 fiches adhérents complètes.

Effectivement, je pense qu'une fois que l'on aura quelquechose d'utilisable (la version CVS est en plein chantier avec les templates), il faudra pas mal bosser sur les script d'install, et surtout d'upgrade. Ca risque d'être délicat, mais pas du tout impossible :)

De toute façon, on ne releasera pas avant d'avoir un truc fonctionnel, y compris pour l'upgrade.

Et d'ailleurs je pense qu'on ne releasera pas avant d'avoir le moteur de recherche...

 J'ai cependant une interrogation : Galette utilise une librairie
 d'abstraction SQL. Ça fonctionne bien le blob, dans ce cas là ?
 Comment on y place des limitations de taille ? Etc.

Le blob existe dans toutes les bases de données modernes que je connais, donc ça ne devrait pas être gènant. Pour la taille, un blob est par définition non limité (ou par la taile du disque), c'est donc niveau code qu'il faudra gèrer la limitation.

Frédéric

Répondre à