Piwigo.org

mathiasm · 2006-03-06 16:12:26

rvelices a écrit:
z0rglub a écrit:
Cela faisait longtemps que je souhaitais déplacer #images.storage_category_id dans #image_category.is_storage et c'était l'occasion. Cela ne rend pas les requêtes spécialement compliquées (en tout cas aucune requête de la partie publique n'est changée) à mon avis et ça simplifie le code à plusieurs endroits. Je ne comprends pas la remarque sur la conception relationnelle de la BD :-/
Bref... je veux bien qu'on s'amuse un peu avec la persistance des liens source/destination en BSF, mais je souhaite retirer tout ça avant la branche 1.6.
Une image a toujours une et une seule categorie comme storage, d'ou naturellement le "storage category" est un attribut de l'image. En le mettant dans image_category -> on peut avoir potentiellement plusieurs categories avec is_storage=true pour la meme image ou on peut ne pas avoir du tout une storage category pour une image. Mais ce n'est pas grave ... je trouvais juste plus naturel le model precedent.

En fait, le risque de plusieurs ou aucune catégorie en is_storage n'existe pas puisque a priori, seules les catégories physiques auront cet attribut à true. En fait, tu définis quelle catégorie est physique (avec true) parmi toutes celles auxquelles l'image est liée. Normalement, c'est mis à jour lors de la synchro (j'ai pas vérifié), donc peu de risques.
Edit:
Pour l'implémentation, ça dépend quand et comment est requêtée l'info en question (quand a-t-on besoin de la catégorie physique?). le fait de stocker l'info dans un champ évite une requête en jointure sur la table categorie. Voir si la fréquence d'usage le nécessite.

Dernière modification par mathiasm (2006-03-06 16:38:28)

rvelices · 2006-03-07 01:48:28

z0rglub a écrit:
Je comprends mieux la remarque. (edit, texte de cette parenthèse à retirer: A mon avis, c'est très subjectif :-) puisque je vais te répondre qu'une contrainte d'unicité sur #image_category.{image_id, category_id, is_storage} est tout à fait équivalent, et qu'il faut que je la rajoute :-)) Tu as raison, ma modification est incohérente. Faut que je réfléchisse aux avantages/inconvénients. Je souhaite éviter les redondances dans la base et les possibilités de désynchronisation.

OK. A toi de voir (si j'avais un mot a dire ca serait retour en arriere). Sinon il reste encore un storage_category_id dans element_set_global (ligne 376).

z0rglub a écrit:
Moi je dis qu'on se donne 2 à 3 semaines pour regarder à l'utilisation, mais qu'on prévoit de supprimer #categories_link (et pas #image_category.is_storage, qui n'a pas de rapport direct avec la fonctionnalité dont nous discutons dans ce topic)

D'accord pour la suppresion de categories_link. J'ai regarde en detail le fonctionnement; personellement je ne voit aucune utilite (si le contenu de #image_category n'etait pas pre-rempli, mais genere a la volee en prenant en compte les permissions alors je verrais une utilite...)

mathiasm · 2006-03-07 02:09:10

après reflexion, pas beaucoup d'utilité, vu qu'on a l'icone de panier pour les catégories. ça ne permet pas une alimentaiton automatique (persistante), mais je n'en vois pas l'intérêt.
Sinon, il suffit de faire ça en MOD (passer l'url de sélection de la cat au caddie, puis affectation du contenu du caddie à la 2e categorie).

plg · 2006-03-07 17:01:19

rvelices a écrit:
OK. A toi de voir (si j'avais un mot a dire ca serait retour en arriere). Sinon il reste encore un storage_category_id dans element_set_global (ligne 376).

En effet, et c'est typiquement le genre de requête qui est simplifié par l'ajout de #image_category.is_storage, on évite ainsi une jointure sur une grosse table (la table #images).

Après réflexion, en fait, il faut un index unique sur #image_category.{image_id,is_storage}, ce qui signifie qu'une image ne peut être lié qu'à une catégorie physique. Franchement, je pense que ce déplacement d'information a plus d'avantages que d'inconvénients. Pour le moment, ce qu'on voit, c'est le code que j'ai dû modifier pour s'appliquer au nouveau modèle. Je n'ai pas encore codé les simplifications permises par le nouveau modèle.

rvelices a écrit:
D'accord pour la suppresion de categories_link. J'ai regarde en detail le fonctionnement; personellement je ne voit aucune utilite (si le contenu de #image_category n'etait pas pre-rempli, mais genere a la volee en prenant en compte les permissions alors je verrais une utilite...)

Je vois bien que tu es déçu par la pauvreté de la fonctionnalité telle que je l'avais imaginé au départ. Mais si on ne prérempli pas #image_category, ton besoin revient en fait à l'utilisation de recherches sauvegardées. Tu fais une recherche sur N catégories, tu enregistres et publie ta recherche et hop, c'est dynamique et accessible depuis le menu. (c'était déjà prévu en 1.5, j'espère avoir le temps de m'en occupe pour la 1.6)

Piwigo.org

Annonce

#31 2006-03-06 16:12:26

Re: [evolution] liens source/destination entre catégories

rvelices a écrit:

z0rglub a écrit:

#32 2006-03-07 01:48:28

Re: [evolution] liens source/destination entre catégories

z0rglub a écrit:

z0rglub a écrit:

#33 2006-03-07 02:09:10

Re: [evolution] liens source/destination entre catégories

#34 2006-03-07 17:01:19

Re: [evolution] liens source/destination entre catégories

rvelices a écrit:

rvelices a écrit:

Pied de page des forums