Recherche via Elasticsearch #4096
Conversation
requirements.txt
Outdated
| @@ -2,6 +2,8 @@ | |||
| pysolr==3.4.0 | |||
| pygments==2.1.3 | |||
| python-social-auth==0.2.19 | |||
| elasticsearch>=2.0.0,<3.0.0 | |||
There was a problem hiding this comment.
Bon, ça, c'est moche, faut que je me fixe une version et que je m'y tienne.
There was a problem hiding this comment.
Tu es en dev, tu mettras la dernière version en date lorsque le WIP sera terminée. (pip freeze tout ça)
|
Salut Pierre, C'est surement pas la priorité mais tu peux noter ça dans quel modèle indexer : #2807. |
|
C'est noté ;) |
| @@ -0,0 +1,34 @@ | |||
| # -*- coding: utf-8 -*- | |||
| from __future__ import unicode_literals | |||
zds/search2/models.py
Outdated
| self.es_already_indexed = True | ||
|
|
||
|
|
||
| class ESDjangoIndexableMixin(ESIndexableMixin, models.Model): |
There was a problem hiding this comment.
Je ne suis pas trop pour dire que c'est un modèle puisque sa sémantique c'est "Mixin".
Maintenant ma relecture ne fait que commencer, peut-être me fourvoie-je.
There was a problem hiding this comment.
Je sais plus trop si j'ai vraiment besoin de mettre le model.Model (parce que je surclasse save(), par exemple) ou si c'est juste une facilité. Je crois que j'ai changé d'avis à un moment mais que j'ai pas tout modifié. Je testerai :)
There was a problem hiding this comment.
Ouais, je confirme, si je le met pas, j'ai des ennuis. Du coup, soit je change le mot Mixin pour autre chose, soit je trouve une autre manière de dériver save()
There was a problem hiding this comment.
Bah plutôt que Mixin je pense que "Abstract" est une bonne chose. D'autant que tu utilises l'attribut de django "abstract = True".
| self.setup_es() | ||
| elif options['action'] == 'index-all': | ||
| self.index_documents(force_reindexing=True) | ||
| elif options['action'] == 'index-flagged': |
There was a problem hiding this comment.
Du coup j'ai pas compris cette notion de "flagged". Peux-tu l'expliquer?
There was a problem hiding this comment.
Ben en gros, ça évite de réindexer ce qui est déjà indexé et qui à priori n'a pas changé. Lorsqu'on récupère les objets à indexer, on ne récupère que ceux qui sont à es_flagged=True. C'est le must_reindex de solr, que d'ailleurs j'aurais probablement du appeller pour ça, mais je me suis fourvoyé avec l'option coté solr, qui s'appelle --only-flagged.
zds/search2/models.py
Outdated
| content_type = cls.__name__.lower() | ||
|
|
||
| # fetch parents | ||
| for base in cls.__bases__: |
There was a problem hiding this comment.
serait-il possible d'ajouter un logger.debug("will iter into %s", cls.__bases__) avant la boucle et un logger.debug("content type is %", content_type") lorsque la boucle est matchée.
de plus en mode "micro optimisation mais au moins on comprend explicitement la volonté du développeur", peux-tu ajouter un "break" s'il te plait?
zds/search2/models.py
Outdated
| :rtype: elasticsearch_dsl.Mapping | ||
| """ | ||
|
|
||
| m = Mapping(self.get_es_content_type()) |
There was a problem hiding this comment.
Sûrement dû au fait que c'est le début du développement. Mais ce n'est jamais une bonne chose de garder des variable monolettrales. (c'est noël, offrons un nouveau mot à notre langue :p)
zds/search2/models.py
Outdated
| data = {} | ||
|
|
||
| for field in fields: | ||
| if exclude_field and field in exclude_field: |
There was a problem hiding this comment.
afin de faire en sorte que cette condition fonctionne aussi dans le cas où exclude_field vaut None, je propose:
excluded_fields = excluded_fields or [] # please note the renaming into excluded_field, let's offer vhf a christmas english code
for field in fields:
if field in excluded_fields:
continue
# nextThere was a problem hiding this comment.
ah, et très objectivement, je le comprend comme exclude a field et pas comme a field is exluded. Mais chui pas bien dans ma tête :p
There was a problem hiding this comment.
"Exclude a field" est une action, ça pourrait être une fonction ou méthode. Ici la variable contient "an excluded field". ;)
zds/search2/models.py
Outdated
| for field in fields: | ||
| if exclude_field and field in exclude_field: | ||
| continue | ||
| v = getattr(self, field, None) |
There was a problem hiding this comment.
Même si le "v" est une sémantique habituelle de "value", je pense que renommer en "value" ne coûtera pas trop cher et rendra le code pérenne.
zds/search2/models.py
Outdated
| obj = objs[index] | ||
| action = 'update' if obj.es_already_indexed and not force_reindexing else 'index' | ||
| objs[index].es_done_indexing(es_id=hit[action]['_id']) | ||
| print(hit) |
There was a problem hiding this comment.
oh? un print. Il faudra le remplacer par un log.info/log.debug.
|
Petite question : comment vas-tu gérer les topics/forums privés dans la recherche. Ne pas les indexer du tout ? Ou alors les indexer et choisir de les afficher en fonction de l'utilisateur (staff ou non) ? J'imagine que ça va peut être t'obliger à indexer des champs supplémentaires ? |
|
Fonctionnellement il faut tout indexer et masquer les résultats auxquels
l'utilisateur n'a pas droit. Sinon la recherche est pétée pour les
utilisateurs avec des droits spéciaux.
Le 24 déc. 2016 5:48 PM, "Anto59290" <notifications@github.com> a écrit :
… Petite question : comment vas-tu gérer les topics/forums privés dans la
recherche. Ne pas les indexer du tout ? Ou alors les indexer et choisir de
les afficher en fonction de l'utilisateur (staff ou non) ? J'imagine que ça
va peut être t'obliger à indexer des champs supplémentaires ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFhKnFPwK_OEiUQkoDlIHEuRI-VHnjMWks5rLUzOgaJpZM4LVOk9>
.
|
|
Autre technique : on indexe tout dont le champ groupe si l'utilisateur
ne fait pas partie d'un groupe on ne requête que les éléments qui n'ont
pas de groupe. Sinon, on prend tous ceux qui n'ont pas de groupe ou dont
l'un des groupes est le groupe de l'utilisateur.
Le langage de requêtage elasticsearch le permet.
Le 24/12/2016 à 17:50, SpaceFox a écrit :
… Fonctionnellement il faut tout indexer et masquer les résultats auxquels
l'utilisateur n'a pas droit. Sinon la recherche est pétée pour les
utilisateurs avec des droits spéciaux.
Le 24 déc. 2016 5:48 PM, "Anto59290" ***@***.***> a écrit :
> Petite question : comment vas-tu gérer les topics/forums privés dans la
> recherche. Ne pas les indexer du tout ? Ou alors les indexer et
choisir de
> les afficher en fonction de l'utilisateur (staff ou non) ? J'imagine
que ça
> va peut être t'obliger à indexer des champs supplémentaires ?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
>
<#4096 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AFhKnFPwK_OEiUQkoDlIHEuRI-VHnjMWks5rLUzOgaJpZM4LVOk9>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABc_xQB6-8Kr48LJRwqgsb7o239MWnWKks5rLU1GgaJpZM4LVOk9>.
|
|
attention ceci est une réflexion à chaud d'une perssonne qui n'a pas l'expérience ou l'expertise nécessaire dans elasticsearch. Pour ce qui est des tokenizers : il me semble que @cgabard a rendu le moteur de markdown capable de gérer un AST ou du moins de générer des méta info bien sympa. On pourrait donc wrapper ce système dans un adaptateur qui permettrait de générer un tokenizing intéressant qui boosterait les mot en fonctions de :
|
|
Faisable, mais je propose qu'on s'y penche dans un 2e temps. 👍 |
|
Clairement . mon message était juste pour dire qu'elasticsearch n'offrait
aucun blocage pour cette problématique là. vue la quantité de texte dans
zds on pourrait presque avoir une stack 100% elasticsearch sans passer par
sql.
Le 24 déc. 2016 6:23 PM, "victor felder" <notifications@github.com> a
écrit :
… Faisable, mais je propose qu'on s'y penche dans un 2e temps. 👍
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABc_xdvbpbrUizWk44dnXk_ce97Cdw46ks5rLVT5gaJpZM4LVOk9>
.
|
Je vais dans le sens des réponses de @SpaceFox et @artragis , tout dois être indexé. Mais comme je dis, faut que je lance un topic avec une réflexion globale sur le sujet :) |
|
A choisir, je préfère qu'on ouvre une issue pour discuter de ça plutôt qu'un topic, ça permet d'avoir un lien entre la PR, le repo et la discussion justifiant les choix qu'on fera. :) |
|
M'en doutais que t'allais dire ça :p Je le fais, parce que j'ai envie d’essayer, mais je trouve que la question "qu'est ce que vous voulez comme résultat d'une recherche" (sans les détails techniques) devrait également être posée sur le forum. @FanJiyong , je te laisse décider de ça :-) GO #4098 !! |
zds/search2/models.py
Outdated
| @@ -100,6 +102,40 @@ def get_es_document_source(self, excluded_fields=None): | |||
|
|
|||
| return data | |||
|
|
|||
| def get_es_document_as_bulk_action(self, index, action='index'): | |||
| """Create a document as formatted in a ``_bulk`` operation. Formatting is done based on action. | |||
There was a problem hiding this comment.
Je fais ce que je peux pour pas tuer ES ;)
zds/search2/models.py
Outdated
| if self.es_id != '': | ||
| document['_id'] = self.es_id | ||
| document['_source'] = self.get_es_document_source() | ||
| if action == 'update': |
| return data | ||
|
|
||
|
|
||
| class FakeChapter(AbstractESIndexable): |
There was a problem hiding this comment.
Bonne question. Parce que c'est pas le vrai conteneur mais une version batarde ?
There was a problem hiding this comment.
En re re relisant, j'ai compris: c'est une sorte de chapitre fantôme que tu utilisais pour toujours avoir un chapitre même quand on a un article.
| def add_arguments(self, parser): | ||
| parser.add_argument('action', type=str) | ||
| parser.add_argument( | ||
| 'action', type=str, help='action to perform, either "setup", "clear", "index-all" or "index-flagged"') |
There was a problem hiding this comment.
Sais-tu que l'argument "choices" existe et te permettra de définir les options disponibles?
There was a problem hiding this comment.
Non. Et pourtant, dieu sais que j'utilise argparse :-°
|
j'ai découvert ça hier avec uncollègue :p
Le 28/12/2016 à 11:45, Pierre Beaujean a écrit :
…
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In zds/search2/management/commands/es_manager.py
<#4096>:
> def add_arguments(self, parser):
- parser.add_argument('action', type=str)
+ parser.add_argument(
+ 'action', type=str, help='action to perform, either "setup", "clear", "index-all" or "index-flagged"')
Non. Et pourtant, dieu sais que j'utilise |argparse| :-°
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4096>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABc_xaqeBAdLmnFib2loqepoyeDmGES2ks5rMj3jgaJpZM4LVOk9>.
|
|
Il est tout à fait probable que ce bug soit en cause de la correction effectuée ici. En tout ca, ça ressemble furieusement à ça (comprendre que c'est plus censé se reproduire) |
|
Ou bien celui là. |
|
@pierre-24 peux-tu stp me résumer la situation ? Dans l'idéal, j'aimerais que ce soit mergé mercredi au plus tard, si possible avant mercredi. En l'état j'arrive pas à déterminer si c'est mergeable ou pas (problème de migrations/travis mis à part). |
|
Basiquement, le bug est du à un truc qui c'est passé par le passé et qui ne
devrait plus se reproduire (y'a deux tests pour ça). J'ai "réglé" le
problème par un "machin if machin else bidule", donc logiquement ça passe
quand même.
Du reste, je pense qu'on est bon ici, sauf erreur de ma part :)
|
|
Super, merci @pierre-24 . Du coup il manque plus que les tests passent sur cette PR et quand c'est vert, on mergera. |
|
C'est un souci de migration: CommandError: Conflicting migrations detected (0016_auto_20170108_1148, 0016_auto_20170201_1940 in tutorialv2; 0011_auto_20170130_1823, 0011_auto_20161224_1310 in forum). |
|
Ah, oui, forcément. Bon, je check Ça quand je rentre du fosdem.
…On Feb 4, 2017 12:33 PM, "Hugo Courtecuisse" ***@***.***> wrote:
C'est un souci de migration:
CommandError: Conflicting migrations detected (0016_auto_20170108_1148,
0016_auto_20170201_1940 in tutorialv2; 0011_auto_20170130_1823,
0011_auto_20161224_1310 in forum).
To fix them run 'python manage.py makemigrations --merge'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHhjCxGK17W6kHYoA6j0Ju9jQPo9BVSGks5rZGHugaJpZM4LVOk9>
.
|
pierre-24
force-pushed
the
add_elasticsearch
branch
from
e9ec98f
to
c03dca7
Compare
|
Voilà, j'ai réglé les souchis de migration, j'ai intégré |
|
@vhf Pour moi, on est bon ! J'ai plus aucune remarque. Je te laisse appuyer sur le bouton final ? |
|
Super, merci ! |
|
Waaaaaw, c'est finalement mergé <3
|
|
Yep, une affaire rondement menée, bravo à tous ! |
|
Je dois donc plein de bières à plein de monde, en particulier à @Situphen
(quand il sera majeur, obviously) :)
|
|
@pierre-24 dans un peu plus d'un mois alors xD y'aura juste un petit problème de distance :-° |
|
T'es pas de Lille, toi ? :P
…On Feb 5, 2017 11:06 AM, "Situphen" ***@***.***> wrote:
@pierre-24 <https://github.com/pierre-24> dans un peu plus d'un mois
alors xD y'aura juste un petit problème de distance :-°
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHhjCzRjnsC9sxc3EdC1lzhGeR27FqWrks5rZZ84gaJpZM4LVOk9>
.
|
|
Nan mais oh ! Je suis breton moi ! :P |
|
Ça peut toujours s'arranger, faut juste que je trouve une excuse pour aller
la bas ;)
…On Feb 5, 2017 11:28 AM, "Situphen" ***@***.***> wrote:
Nan mais oh ! Je suis breton moi ! :P
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4096 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHhjC23oGAbjxtqLedeuGeK1Ey6ep1uBks5rZaRdgaJpZM4LVOk9>
.
|
Joyeux noël, zeste de savoir ! Ça fait 2 mois que je me suis proposé, mais cette fois-ci, c'est officiel, je m'y attaque. But du jeu : virer Solr et utiliser elasticsearch !
Pourquoi ?
analyzeret destokenizerparticulièrement puissants ;Comment ?
index="not_analyzed").Je tiens à créditer le package django-el pour certaines des idées et manières de faire.
TODO
Pour le moment, j'ai fait comme avec la ZEP-12, je travaille sur
zds/searchv2/pour éviter les rebases trop chiants (même si il y en aura).print()PublishedContent, qui doivent être modifié convenablement quand ils sont mis à jour)pip freeze(et d'ici là, ce sera probablement plus la 5.1.1).zds/search/?Attendre la ZEP-13.À discuter → #4098
Sujet sur le forum à venir, probablement demain, sauf si @vhf préfère pas.
QA
C'est à peu près OK, mais il faudra tester sur le "vrai zds" pour ajuster les différents paramètres de boost.
python ./manage.py es_manager index-all. Une fois que c'est fait, vous pouvez vous amuser à créer des topics, posts ou publier des contenus et utiliserpython ./manage.py es_manager index-flaggedpour mettre à jour l'index.Un peu de screenshots: