Non, mais maintenant je saurais quoi faire pour faire implémenter mes idées, c'est tout !

Bizarrement, j'ai pas d'idées, là maintenant.

Est-ce que vous trouvez que les possibilités de filtrer par auteur et par plage de dates est un must-have ?

Non, un bonus par contre, mais pas obligatoire

Et lors de la recherche par message, c'est vraiment le contenu du message qui vous intéresse, ou plutôt la combinaison "titre de discussion + fragment de message" ?

J'essaie de voir s'il est nécessaire d'envisager du faceting ou pas (possibilité de pouvoir raffiner la recherche petit à petit).

Perso je cherche plutôt le contenu du message, par exemple je cherche Windows 10, Firefox, Forza, etc.

Mais bon, au niveau de la query SQL, tu as juste un title = "%search%" or message = "%search%", ça fait pas une grosse différence, si ?

Vu qu'on utilise la recherche 1x/mois, tu peux laisser une requête un peu lourde

PetitCalgonMais bon, au niveau de la query SQL, tu as juste un title = "%search%" or message = "%search%", ça fait pas une grosse différence, si ?

C'est pas trop éloigné, mais pas si simple que ça, vu que pour l'instant, je parse la chaîne recherchée afin de supporter des opérateurs booléens et la recherche par guillemets.

La question est plutôt : comment organiser/présenter les résultats ?

Si la recherche porte sur les messages, on pourrait être tenté d'afficher uniquement les messages "matchant" la requête, et de produire un lien direct vers ce message. Mais le contexte du message est important (ie. son topic). Dans ce cas, il convient d'afficher aussi le titre du topic. Ok, mais si j'ai 15 messages dans un même topic, et que 10 d'entre eux satisfont la recherche, est-ce que ce topic ne devrait pas être affiché comme "plus pertinent" ? Je me demande s'il ne serait pas plus judicieux de considérer le topic comme l'unité de recherche, dont le contenu est défini par les messages. Mais dans ce cas, la page de résultats contiendra juste les topics (et les morceaux de messages). Il faut que je trouve une astuce pour permettre de remonter au bon message directement depuis l'affichage du résultat.

Un peu comme si, sur Google, si tu cherches "PetitCalgon", ça t'affiche www.lexpage.net avec, en dessous, les endroits du site où on parle de PetitCalgon versus une liste exacte des pages où on trouve PetitCalgon, peu importe que ça soit sur le même site ou que l'ordre des sites ne dépend pas de la pertinence du résultat.

En général, on peut utiliser une technique de faceting pour régler ce souci : on fait la recherche par message, on liste les topics et les extraits concernés par la recherche, et quand tu cliques sur le topic, ça affiche uniquement les messages de ce topic qui sont pertinents. Dans ce cas, on peut alors immédiatement aller au bon message sur le bon topic.

Je trouve cette recherche plus intéressante : on peut rechercher à la fois un topic et des messages, et la pertinence d'un topic est fonction de la pertinence des messages qu'il contient. Si je cherche "Lexpage and GitHub", je m'attends à voir le topic "Lexpage enfin sur GitHub" ressortir non pas parce que le titre contient ces deux mots, mais plutôt parce que le contenu du topic (au sens large) fait souvent mention de ces deux éléments. Le "hic" : c'est que je n'ai aucun moyen, lorsque j'affiche les résultats, de savoir si la personne souhaite trouver le topic, ou si la personne souhaite trouver un message spécifique (par exemple, celui qui annonce que Lexpage est enfin sur GitHub). Dans le premier cas, mon unité de base est le "topic", et le "document" dans lequel je fais la recherche est l'ensemble du thread. Dans le deuxième cas, l'unité de base est le "message" qui est également le document dans lequel je fais la recherche. Dans le premier cas, je peux fournir un lien direct vers le topic (mais pas vers le message, ou tout du moins, si j'utilise une solution "presque prête" comme Haystack), alors que dans le second cas, je peux fournir un lien vers le message ET vers le topic (mais je ne peux pas définir une "pertinence" pour le topic).

Pour résumer, savoir comment vous utilisez la recherche m'aiderait à trancher pour l'une ou l'autre approche. Si l'objectif est de trouver le topic contenant le message recherché (et donc la recherche porte en réalité sur le contenu du topic et non spécifiquement d'un message), alors j'opterai pour l'approche (1). Si l'objectif est de trouver spécifiquement un message (parce que vous voulez spécifiquement réagir ou relire celui-là, indépendamment de son topic), alors il faut que j'opte pour l'option (2).

Les deux : j'ai déjà recherché des termes que je sais avoir été présents dans un topic pour déterrer le topic. Et à d'autres fois, recherché une argumentation particulière.

Ex : "je cherche le topic elite, je cherche elite, je tombe sur le topic elite" vs "je cherche où on a parlé de tel truc, je cherche ce truc, ce message en particulier"

J'ai utilisé les deux.

Pour moi, un moteur à facettes, c'est un truc bien particulier, qui demande pas mal de puissance, et qui est ultra puissant. Genre j'ai une instance d'open-search-server et une de solr, et je sais que ces machins tourneront pas sur ton petit dédié. Que fait exactement haystack, c'est bien pypi.python.org/pypi/hay… parce que j'ai un doute là ?

Haystack est juste un gros wrapper dans Django pour lequel on peut définir le backend à utiliser pour la recherche (ElasticSearch, solr, etc.).

Coté backend, par facilité, je vais opter pour whoosh (qui est supporté par Haystack) parce que c'est du pur Python et que les autres solutions sont "too much" pour moi (et pour le VPS, en effet). Accessoirement, il ne supporte pas encore le faceting Enfin, je raconte tout ça mais il n'est pas encore clair qu'Haystack puisse répondre à mes besoins, et je n'exclus pas une solution "maison".

Disons que pour l'instant, vu vos retours, j'ai l'impression que pré-sélectionner "Messages des discussions" dans la fonction de recherche actuelle suffirait pour répondre à vos attentes

Quelques nouvelles :
- Haystack est compatible Python 3, mais pas une de ses dépendances (!), enfin, pas directement depuis PyPi (mais bien depuis GitHub). Comme je n'ai pas envie de rendre l'environnement dépendant de facteurs (trop) externes, je me suis abstenu de tester la recherche avec Haystack. Je travaillerai directement avec Whoosh si besoin, et je coderai moi même le wrapper pour l'intégrer à Django.
- La recherche supporte maintenant le minichat et les slogans. J'en ai profité pour modifier la manière dont des éléments supplémentaires peuvent être intégrés au moteur, ce qui rendra son extension plus simple à l'avenir.
- La recherche sélectionne, par défaut, "Discussions - messages", au lieu des billets, suivant les retours que vous avez fournis sur le topic.

Je continue de regarder les alternatives et ce qui pourrait être fait pour améliorer cette fonction (un peu marginale, il faut le reconnaître), mais cette petite mise à jour dépannera en attendant mieux.

Tiens, as-tu essayer de rechercher un utilisateur? C'est idiot ça ne sert à rien
J'ai cherché "acibi", je l'ai effectivement trouvé, mais il n'y a pas de lien pour aller sur son profil, à quoi ça sert

Corrigé. Par défaut, les utilisateurs (User de Django) n'ont pas d'URL inverse définie.

[Edit : le changement n'apparaitra pas en ligne immédiatement, il faut le temps que les processes redémarrent une nouvelle instance du Lexpage, j'ai préféré ne pas redémarrer manuellement vu la faible modification ]

Merci d'avoir signalé le bug