Le problème de base est la recherche sur plusieurs mots.

Je suis d'accord avec www.photons.fr, par défaut, on devrait sortir du "ET" et pas du "OU", sinon plus la chaîne recherchée est longue, plus il y aura de résultat, ce qui n'a pas de sens, puisqu'en précisant la recherche (= en allongeant la chaîne recherchée) on devrait diminuer le nombre de résultats, comme quand on navigue par tag en affichant d'abord "Pierre" puis "Pierre + New York" et enfin "Pierrick + New York + nuit".

Avec la recherche rapide, au lieu de taper "mot1 mot2", pour être sûr d'avoir les 2 mots, il faut taper "+mot1 +mot2", ce qui relève en effet du jargon d'informaticien et n'est donc pas à exiger des utilisateurs.

La requête SQL pour le nom/description des photos est :

SELECT i.id,
    MATCH(i.name, i.comment) AGAINST( 'erwann tiphaine' IN BOOLEAN MODE) AS weight
  FROM piwigo_images i
  WHERE (MATCH(i.name, i.comment) AGAINST( 'erwann tiphaine' IN BOOLEAN MODE)
    OR (CONVERT(file, CHAR) LIKE '%erwann%' OR CONVERT(file, CHAR) LIKE '%tiphaine%'))
;

Avec la recherche "avancée", l'équivalent est :

SELECT DISTINCT(id)
  FROM piwigo_images
  WHERE (
         (file LIKE '%erwann%'
          OR name LIKE '%erwann%'
          OR comment LIKE '%erwann%'
          OR author LIKE '%erwann%')
         AND
         (file LIKE '%tiphaine%'
          OR name LIKE '%tiphaine%'
          OR comment LIKE '%tiphaine%'
          OR author LIKE '%tiphaine%'))
;

C'est sans doute moins puissant du point de vue utilisation des possibilités de MySQL, mais ça fournit un résultat plus juste : seules les photos qui contiennent "erwann" dans l'un de champs {file, name, comment, author} et "tiphaine" dans l'un des champs {file, name, comment, author}  sortira de cette requête.

Pour les tags, ça me semble plus compliqué. Imaginons que j'ai les tags suivants : "Erwann", "Erwann à la plage", "Erwann fait le pitre", "Tiphaine", "Tiphaine à la mer", "Tiphaine à la montagne", "Tiphaine à l'école", "Tiphaine et Erwann mangent des pommes" et enfin le fameux "Erwann et Tiphaine font les guignols" (je pourrais en avoir un paquet des photos taggées comme ça).

Il faudrait des groupes de photos selon les tags :

1) les 110 photos qui sont liées à l'un des 3 tags qui matchent "erwann"
2) les 234 photos qui sont liées à l'un des 4 tags qui matchent "tiphaine"
3) les 12 photos qui sont liées à l'un des 2 tags qui matchent "erwann" et "tiphaine"

Les photos valides sont celles qui appartiennent aux groupes 1 et 2 ou au groupe 3.

sur ma base j'ai deux type de rivieres:

la drome
l'ardèche


si je tape dans recherche simple:

drome et riviere

le moteur de recherche affiche toutes les photos de riviere mais egalement toutes les photos de la drome?

faut il supprimer dans la legende drome?et seulement rajouter un tag DROME a toutes les photos pour resoudre le probleme

plg a écrit:

jeanjon a écrit:

faut il supprimer dans la legende drome?et seulement rajouter un tag DROME a toutes les photos pour resoudre le probleme

Le plus sûr est de passer par les tags et demander à afficher les photos tagguées "drome" puis cliquer sur "+ riviere" dans la liste des tags liés qui s'affiche dans la barre de menu. C'est l'idéal en terme de précision. Encore faut-il avoir taggué toutes ses photos.

... et encore faut-il que le visiteur lambda sache utiliser ce procédé.

Une recherche donne un résultat et en général on se satisfait de ce résultat. S'il faut affiner (ce qui est super en soi !) autant prévenir dès le début, avant même le lancement de la recherche qui porterai sur une requête trop précise Ex : drome et riviere

M'enfin on s'éloigne de la demande qui porte sur un nouvelle fonctionnalité (ou sur une prestation privée).

rvelices a écrit:

Pas d'accord, car avec le MATCH full text on aura un ordre des images. Le poids: d'abord les photos qui contiennent Erwan ET Tiphaine suivies par celles qui contient soit l'un soit l'autre.

Mettons de côté le problème des tags qui fonctionnent en mode OU.

Que l'on place les résultats contenant les 2 mots en premiers, c'est bien. Mais il ne faudrait pas montrer les autres du tout. Quand la recherche est un mode de navigation majeur d'une galerie, sortir des résultats en OU paraît clairement erroné. C'est un point de vue bien sûr.

rvelices a écrit:

En fait si tu veut avoir de ET, c'est possible en cherchant +erwan +tiphaine

Oui, c'est mieux avec les "+". Ne pourrait-on pas ajouter automatiquement les "+" devant chaque mot avant de lancer la requête SQL ?

Par ailleurs, je ne sais pas comment se comporte PostgreSQL, je suppose que ça ne marche pas.

L'utilisation de MATCH AGAINST, c'est sans doute très intéressant, mais j'ai du mal à voir l'argument percutant par rapport au LIKE. Certes la requête est plus simple en MATCH AGAINST (surtout s'il y a de nombreux mots à dans la requête de recherche). Pour le moment, telle que je la comprends, la notion de "poids" n'a de sens que parce qu'on peut afficher du OU. Si on considère que l'on doit faire du ET, le poids n'a plus d'intérêt.

rvelices a écrit:

plg a écrit:

Pour les tags, ça me semble plus compliqué....

C'est exact - pour faire bien il faudra faire N requetes sur les tags ou ma solution (utilisé aussi par gallery 3) qui consiste à avoir une table avec image_id, concat(nom, description, tags, categories etc ...).

hum... un cache à la fois gourmand en volume et  qui va nécessiter une mise à jour à chaque modification des propriétés de la photo, du nom du tag, de l'association d'un tag, de la modification de la description de l'album, etc. => complexe.

Si Piwigo était prioritairement un moteur de recherche de photo, je dirais que c'est une une très bonne voie à suivre, mais ce n'est pas le cas.

Alors certes pour faire bien les choses, il y a davantage de requêtes SQL à faire pour trouver les bonnes photos, mais ce n'est pas non plus une augmentation exponentielle. Pour N mots dans la recherche, on va faire N+1 requêtes sur la table des tags.

Bonjour,

Je n'arrive pas à modifier correctement cette recherche sans que cela m'affiche des erreurs une fois sur 3 ou 4 recherches. De plus, je crains que lors de prochaines mises à jour piwigo mes bricolages ne provoquent encore plus d'effets de bord. Donc c'est assez risqué.

J'avais demandé plus haut si il était possible que le team piwi nous fasse une modif propre et pérenne. Ma question tient toujours.... :o)))

Amitiés,

Georges

rvelices a écrit:

Je vais ameliorer la recherche rapide notamment le matching de tags. Je ne sais pas quand j'aurai le temps, mais ca sera probablement dans la prochaine version 2.2 ou au pire des cas pour la 2.2.1

Bonne nouvelle ! Merci RVelices :-)

ça été fait il y a quelques heures, comme l'a dit rvelices ça sera intégré pour le 2.2.1
http://piwigo.org/dev/changeset/10340

si vous êtes vraiment pressé vous pouvez télécharger le nouvelle version du fichier (en sauvegardant l'original !)

Dernière modification par mistic100 (2011-04-13 16:20:13)

lien de dl :
http://piwigo.org/dev/export/10340/trun … ch.inc.php