🌍
Français
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)
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).
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...)
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.
rvelices a écrit:
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.
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.
rvelices a écrit:
Si tu veux le retirer pour la 1.6 pas de pb.
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)
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.
Si tu veux le retirer pour la 1.6 pas de pb.
mathiasm a écrit:
Dans [Subversion] r1064, il y a un bug a priori dans 10-database.php => Pas de prefix_table ...
Voilà, c'est corrigé dans [Subversion] r1065.
mathiasm a écrit:
A mon avis tu t'es trop pris la tête pour la gestion de l'admin:
Supprime le bloc "Create a destination category", qui ne sert à rien (création de cat virtuelle).
C'est marrant, parce que c'est uniquement ça mon besoin initial. C'est vraiment le seul intérêt que je vois personnellement à cette fonctionnalité : pouvoir créer un catégorie virtuelle à laquelle j'associe toutes les photos de ma catégorie physique courante.
mathiasm a écrit:
Je pense que c'est plus un problème de nommage qui rend ça troublant.
Au lieu de source/destination, j'aurai plutot vu une notion d'incorporation de contenu:
Ce qu'on fait, c'est bien incorporer (intégrer, rattacher, relier?) le contenu d'une catégorie à celui d'une autre ?
Non, car il y a plusieurs façon d'alimenter des catégories : liens ajoutés manuellement, ajout par FTP. Personnellement, ce n'est pas la terminologie qui me trouble :-) mais la montagne de code associée.
rvelices a écrit:
Si t'as deja passe du temps dessus, pourquoi l'enlever ?
Parce que le besoin de départ était simple et que ça s'est transformé en un code complexe qui sera difficile à maintenir pour aboutir à une fonctionnalité intéressante, mais franchement pas très utile (je parle de la persistance). Les possibilités qu'elle permet sont disponibles via d'autres fonctionnalités.
Peut-être que j'ai mal conçu le code en l'occurence, mais c'est merdique. Il faut savoir reconnaître quand on a fait une erreur, cette fonctionnalité est une erreur.
rvelices a écrit:
Ca a l'air de tres bien marcher.
Non, ça marche de manière bancale pour le moment, dans le [Subversion] r1065 que je viens de commiter, j'ai rajouté le support des associations/dissociations manuelles ultérieures à la création du lien source/destination.
rvelices a écrit:
(la seule choese: je n'ai pas bien compris pourquoi storage_category_id est passe dans l'autre table... ca rend d'autres requetes plus complexes et ce n'est pas tres "conception BD relationnelle" ... ).
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.
Si t'as deja passe du temps dessus, pourquoi l'enlever ? Ca a l'air de tres bien marcher. (la seule choese: je n'ai pas bien compris pourquoi storage_category_id est passe dans l'autre table... ca rend d'autres requetes plus complexes et ce n'est pas tres "conception BD relationnelle" ... ).
Dans [Subversion] r1064, il y a un bug a priori dans 10-database.php => Pas de prefix_table ...
Sinon, un petit retour:
A mon avis tu t'es trop pris la tête pour la gestion de l'admin:
Supprime le bloc "Create a destination category", qui ne sert à rien (création de cat virtuelle).
Tu fais un bloc "Alimentation de catégories" (Category fill/feed?) dans lequel tu insères les 2 autres blocs avec les doubles select.
Je pense que c'est plus un problème de nommage qui rend ça troublant.
Au lieu de source/destination, j'aurai plutot vu une notion d'incorporation de contenu:
Ce qu'on fait, c'est bien incorporer (intégrer, rattacher, relier?) le contenu d'une catégorie à celui d'une autre ?
Voilà, c'est dans [Subversion] r1064. Ca marche, mais que de code pour une fonctionnalité si avancée et pas très utile finalement, puisqu'elle ne peut rien faire d'inédit :-/ (je suis énervé d'avoir passé tant de temps dessus alors que d'autres fonctionnalité sont bien plus importantes).
J'ai l'impression que je ne vais jamais réussir à finir ce dev :-/ J'en suis à plus de 500 lignes de PHP assez complexes (manipulation de tableaux dans tous les sens). Alors que mon besoin initial se code en quelques lignes et que finalement je ne pense pas que la persistance et la possibilité d'avoir N sources et N destinations ait un intérêt : c'est bien trop complexe pour 99,9% des utilisateurs. Je pense aussi à la maintenabilité :-/
Bref, je vais commiter bientôt, mais je sens que je vais revenir à mon besoin initial qui s'obtient en quelques lignes. Le code sera de toute façon dans le gestionnaire de version...
z0rglub a écrit:
mathiasm a écrit:
mets en oeuvre selon ta version, ce sera la première marche... Si ça passe en 1.6, les evol° passeront en version mineure.
De préférence non. Les évolutions fonctionnelles ne sont autorisées que sur la branche de développement, les branches stables sont dédiées à la stabilisation, donc à la correction de bugs bloquant et peu impactant.
Et dire que c'est moi qui l'ai écrit dans le wiki :-/ Quelle honte!
Donc mets en oeuvre ta solution, on la teste en BSF, et on verra ce qui manque réellement. Rien ne vaut un peu de pratique.
z0rglub a écrit:
mathiasm a écrit:
Autre ex.: une catégorie tous les Noëls, tous les anniv,etc
Là, je ne suis pas d'accord, c'est la classification par tag qui devrait être mise à profit en l'occurence.
Oui, je ne l'oublie pas, mais dans l'attente... ;-). Et certains usagers préfèreront gérer ça par alimentation plutot que par tag.
mathiasm a écrit:
mets en oeuvre selon ta version, ce sera la première marche... Si ça passe en 1.6, les evol° passeront en version mineure.
De préférence non. Les évolutions fonctionnelles ne sont autorisées que sur la branche de développement, les branches stables sont dédiées à la stabilisation, donc à la correction de bugs bloquant et peu impactant.
mathiasm a écrit:
Ta persistance est la bienvenue dès lors qu'on veut une catégorie tous les xxx:
cas simple:
- catégorie E avec toutes les photos d'Elodie.
- catégorie P avec toutes les photos de Pauline, sa soeur.
Si je veux une catégorie S avec toutes les photos des 2 soeurs, je la relie aux cat P et E et c'est tout bon
Je suis d'accord, les liens source/destination vont résoudre avec élégance ce genre de problèmatique.
mathiasm a écrit:
Autre ex.: une catégorie tous les Noëls, tous les anniv,etc
Là, je ne suis pas d'accord, c'est la classification par tag qui devrait être mise à profit en l'occurence.
mets en oeuvre selon ta version, ce sera la première marche... Si ça passe en 1.6, les evol° passeront en version mineure. On aura alors de la visibilité pour savoir si la première marche était assez grande pour arriver au bout de la fonctionnalité, ou s'il en faut d'autres.
Ta persistance est la bienvenue dès lors qu'on veut une catégorie tous les xxx:
cas simple:
- catégorie E avec toutes les photos d'Elodie.
- catégorie P avec toutes les photos de Pauline, sa soeur.
Si je veux une catégorie S avec toutes les photos des 2 soeurs, je la relie aux cat P et E et c'est tout bon
Autre ex.: une catégorie tous les Noëls, tous les anniv,etc
mathiasm a écrit:
z0rglub a écrit:
Je tiens à noter que cette fonctionnalité va largement au-delà de mon besoin initial, puisque celui-ci était surtout ergonomique... puis j'ai voulu ajouter la notion de persistance, et là tout se complique.
Par persistance, tu entends [...]
Par persistance, j'entends le fait que si j'ai déclaré A source de C, alors ultérieurement, toute association d'image à A entraîne la création d'une association d'image à C.
Mon besoin initial était juste de pouvoir créer une catégorie virtuelle dans l'écran de gestion de la catégorie physique, avec création des liens image/catégorie entre les photos de la catégorie physique et la catégorie nouvelle virtuelle. Comme mes catégories physiques sont évenementielles, une fois remplies, elles ne sont plus jamais mise à jour. Donc je n'ai pas besoin de persistance personnellement. D'où le fait que j'ai déjà élevé le niveau d'exigences, là j'ai peur que vous ne le surrélevier ;-)