photo credit :  »grahamblackall

Release an open-source software once, and you’ll be doomed to maintain it for life.

This is just a quick message to let you know that I’ve released a new version of my Symfony Solr plugin : tjSolrDoctrineBehaviorPlugin.

This plugin allows you to easily index and search among your doctrine objects. Wanna see the changelog ?

• I18n integration
• Configure Solr and Jetty logging
• Realtime indexing option
• DataImportHandler (DIH) configuration
• Task to rebuild index
• Update documentation
• Bug corrections

I hope you will find it useful. Happy new year !

photo credit : Thibault Jouannic

Drôle d’époque. Après deux jours magiques à ParisWeb, et un retour chez moi dans une ambiance de guerre civile, le retour à la réalité est… difficile.

La reprise du quotidien après un tel événement est toujours une période cafardogène. Pour éviter de sombrer dans la déprime la plus grise, je vous propose de nous fixer un objectif un tantinet ambitieux : et si nous indexions la plus grande base de connaissance au monde dans le meilleur moteur de recherche ? (Si ça ne vous plait pas, vous pouvez plutôt vous abonner au tag #sudweb.)

Chercher dans Wikipédia grâce à Solr ? Si, c’est possible.

Des données, des données, des données…

Wikipédia fournit régulièrement des fichiers de dumps permettant de récupérer toutes les données du site. Nous nous contenterons de récupérer les articles complets (sans les révisions, ni les commentaires), et en français uniquement. Je vous mâche le travail, il n’y a qu’un seul fichier à récupérer.

Configurer le schéma

La documentation de Solr fournit un exemple de schéma pour indexer Wikipedia. Nous allons l’optimiser pour prendre en compte la langue française (je pars ici d’une install vierge de Solr).

Commençons par ajouter un nouveau fieldtype : text_fr, dans le fichier schema.xml.

<fieldtype name="text_fr" class="solr.TextField">
  <analyzer type="index">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.SynonymFilterFactory" synonyms="synonyms_fr.txt" ignoreCase="true" expand="true"/>
    <filter class="solr.StandardFilterFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords_fr.txt"/>
    <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange=
    <filter class="solr.ISOLatin1AccentFilterFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.SnowballPorterFilterFactory" language="French" protected="protwords_fr.txt" />
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.StandardTokenizerFactory"/>
    <filter class="solr.SynonymFilterFactory" synonyms="synonyms_fr.txt" ignoreCase="true" expand="true"/>
    <filter class="solr.StandardFilterFactory"/>
    <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords_fr.txt"/>
    <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange=
    <filter class="solr.ISOLatin1AccentFilterFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.SnowballPorterFilterFactory" language="French" protected="protwords_fr.txt" />
  </analyzer>
</fieldtype>

Vous remarquerez que ce type de champ nécessite trois fichiers pour fonctionner.

1. synonyms_fr.txt, pour gérer les synonymes dans l’indexation. Exemple :

   aiki => aikido
   resto => restaurant
   

2. stopwords_fr.txt, contient la liste des mots basiques qui ne doivent pas être indexés  ;
3. protwords_fr.txt, contient la liste des mots qui ne doivent pas être retraités par le stemmer français  ;

Ensuite, toujours dans le même fichier, configurons nos fields :

<fields>
  <field name="id"        type="string" indexed="true" stored="true" required="true"/>
 
  <field name="title"     type="string"     indexed="false" stored="true"/>
  <field name="search_title"     type="text_fr"     indexed="true" stored="false"/>
  <field name="body"    type="text_fr"    indexed="true" stored="true" termVectors="true"/>
 
  <field name="revision"   type="sint"    indexed="true" stored="true"/>
  <field name="user"        type="string"  indexed="true" stored="true"/>
  <field name="userId"     type="int" indexed="true" stored="true"/>
  <field name="timestamp" type="date"    indexed="true" stored="true"/>
 </fields>
 
 <uniqueKey>id</uniqueKey>
 <defaultSearchField>search_title</defaultSearchField>
 <copyField source="title" dest="search_title"/>

Notez que l’on stocke le corps de l’article. C’est parce que nous allons utiliser les results highlighting. Si vous n’avez pas besoin de cette fonctionnalité, remplacez « stored=true » par « stored=false ».

Et on importe

Nous aurions pu décider de convertir le fichier xml de wikidédia en sql, de l’importer dans une base, et d’utiliser un sql import handler. Mais pourquoi se compliquer la tâche ? Solr peut importer directement du xml. Configurons notre import de données dans le fichier data-config.xml :

<dataConfig>
    <dataSource type="FileDataSource" encoding="UTF-8" />
    <document>
    <entity name="page"
        processor="XPathEntityProcessor"
        stream="true"
        forEach="/mediawiki/page/"
        url="/var/www/solrdemo/dumps/frwiki-latest-pages-articles.xml"
        transformer="RegexTransformer,DateFormatTransformer"
        >
        <field column="id"    xpath="/mediawiki/page/id" />
        <field column="title"     xpath="/mediawiki/page/title" />
        <field column="body"      xpath="/mediawiki/page/revision/text" />
        <field column="revision"  xpath="/mediawiki/page/revision/id" />
        <field column="user"      xpath="/mediawiki/page/revision/contributor/username" />
        <field column="userId"    xpath="/mediawiki/page/revision/contributor/id" />
        <field column="timestamp" xpath="/mediawiki/page/revision/timestamp" dateTimeFormat="yyyy-MM-dd'T'hh:mm:ss'Z'" />
        <field column="$skipDoc"  regex="^(?i)#redirect.*" replaceWith="true" sourceColName="text"/>
       </entity>
    </document>
</dataConfig>

Redémarrez Solr, lancez l’indexation, attendez (une heure ou deux), et paf ! 2400000 document indexés, ce qui vous en conviendrez est plus que suffisant pour s’amuser.

Un peu de result highlighting

Étant donné que nous disposons d’un sacré paquet de texte, autant en profiter un peu, non ? (oui, j’ai des loisirs de geeks). Au hasard, je vous propose de mettre en place un peu de result highlighting^[1] .

Bon, alors pour ceux qui aiment bien avoir un retour visuel, ça pourrait ressembler à ça :

Pour ce faire, nous allons utiliser les paramètres qui vont bien, et que je vous propose ci-dessous sous forme de tableau php (et tant pis pour les pythoneux, faudra s’en contenter^[2] ).

$req = array(
  'q' => 'Ma recherche',
  'qt' => 'dismax', // Nous envoyons directement le contenu du formulaire à Solr, par conséquent dismax est plus adapté
  'qf' => 'title^2 body', // On cherche dans title et body, avec une priorité plus importante pour le champ title
  'hl' => 'true', // Activitation de l'highlighting
  'hl.fl' => 'title,body',  // Seuls ces champs seront pris en compte pour la surbrillance
  'f.body.hl.alternateField' => 'body',  // Si aucun snippet n'est trouvé dans le champ body, on renvoie le champ complet
  'hl.fragsize' => 150,  // Les snippets font 150 caractères…
  'hl.snippets' => 3,  // … et on renvoie 3 snippets maxi 
  'hl.maxAlternateFieldLength' => 200,  // Si on renvoie le champ body comple, on limite à 200 caractères
  'hl.simple.pre' => '<strong>',  // On veut que notre surbrillance soit encadrée par des balises 'strong'
  'hl.simple.post' => '</strong>',
));

Si vous exécutez une requête contenant ces paramètres, vous noterez que la réponse est séparée en deux parties : d’un côté, les résultats, et de l’autre, les snippets générés. Vous remarquerez également que les snippets en question sont a peu près illisibles à l’œil nu, mais ça, c’est une autre histoire.

<?xml version="1.0" encoding="UTF-8"?>
<response>
<responseHeader>
  <bla>bla</bla>
</responseHeader>
<result name="response" numFound="50" start="0">
  <doc>
    <str name="id">9</str>
    <int name="revision">2338009</int>
    <date name="timestamp">2002-10-31T09:16:01Z</date>
    <str name="title">Algèbre de boole</str>
  </doc>
…
</result>
<lst name="highlighting">
  <lst name="9">
    <arr name="body">
      <str>
L' &lt;em&gt;alg&amp;#232;bre&lt;/em&gt; g&amp;#233;n&amp;#233;rale, ou &lt;em&gt;alg&amp;#232;bre&lt;/em&gt; abstraite, est la branche des math&amp;#233;matiques qui porte principalement sur l'&amp;#233;tude des structures &lt;em&gt;alg&amp;#233;briques&lt;/em&gt; et de leurs relations. L'appellation &lt;em&gt;alg&amp;#232;bre&lt;/em&gt; g&amp;#233;n&amp;#233;rale s'oppose &amp;#224; celle dalg&amp;#232;bre &amp;#233;l&amp;#233;mentaire ; cette derni&amp;#232;re enseigne le calcul &lt;em&gt;alg&amp;#233;brique&lt;/em&gt;, c'est-&amp;#224;-dire les r&amp;#232;gles de manipulation des formules et des expressions &lt;em&gt;alg&amp;#233;briques&lt;/em&gt;.Historiquement, les structures &lt;em&gt;alg&amp;#233;briques&lt;/em&gt; sont apparues dans diff&amp;#233;rents</str>
    </arr>
  </lst>
…

Parser la réponse sera finalement assez simple. Allez, je vous donne le code que j’utilise (pour les curieux, c’est du twig, mais ce serait pareil avec n’importe quel autre moteur de template).

<section id="results">
  {% block results %}
    <h3>{{ results.numFound }} résultats trouvés</h3>
    <ol>
    {% for doc in results.docs %}
      {% block doc %}
        <li>
          <a href="http://fr.wikipedia.org/wiki/{{ doc.title }}" />{{ doc.title }}</a>
          <p>
          {% for snippet in highlighting[doc.id].body %}
            {{ snippet }}…
          {% endfor %}
          </p>
        </li>
      {% endblock %}
    {% endfor %}
    </ol>
  {% endblock %}
</section>
{% endif %}
</section>

Mais… Mais… Attendez ! C’est tout crade !

Ok, j’avoue, si vous avez vous même testé tout ça jusqu’ici, vous avez remarqué que le résultat n’est pas vraiment exploitable. Le texte que nous indexons, en effet, n’est pas du texte brut : il contient toutes les balises de formattage spécifiques du langage wiki de Wikipédia.

Dans notre cas, nous n’aurons jamais besoin de ces informations aussi l’idéal serait de pouvoir filtrer ces balises dés l’import des données.

Si vous aussi, vous lisez la documentation de Solr en famille le soir au coin du feu^[3], vous savez déjà que Solr propose des transformers (rien à voir avec les robots), qui permettent de filtrer les données lors de l’import.

D’ailleurs, si vous regardez le code du fichier data-config.xml que nous avons utilisé, il utilise déjà deux transformers. Tout ce que nous allons faire, c’est créer notre transformer custom. Allez hop ! Un peu de java ! Créez un fichier WikiTransformer.java

import java.util.*;
import java.io.*;
import info.bliki.wiki.filter.PlainTextConverter;
import info.bliki.wiki.model.WikiModel;
 
public class WikiTransformerAlt {
  public Object transformRow(Map<String, Object> row) {
    String body = (String)row.get("body");
 
    StringWriter writer = new StringWriter();
 
    WikiModel wikiModel = new WikiModel("http://www.mywiki.com/wiki/${image}", "http://www.mywiki.com/wiki/${title}");
    String plainStr = wikiModel.render(new PlainTextConverter(), body);
 
    row.put("body", plainStr);
 
    return row;
  }
}

Deux choses à noter : ce transformer n’est pas optimal, le nom du champ à parser (body) est codé en dur. Mais bon, ça ira pour cette fois (mais ne recommencez pas). Deuxième chose, j’utilise la librairie java gwtwiki pour faire le boulot de traduction wiki -> texte brut. Cette librairie est pour le moment lacunaire (ou alors je m’en sert mal), et le résultat ne sera pas parfait. Il faudra faire avec.

La compilation du fichier en .jar et son installation sortent du scope de cet article, aussi je vous laisse utiliser votre moteur de recherche favori… Bon, ok, je vous file les commandes :

javac -cp "/path/vers/bliki/info.bliki.wiki/bliki-core/target/*" WikiTransformer.java
jar -cf WikiTransformer.jar WikiTransformer.class
cp WikiTransformer.jar path/vers/solr/work/Jetty_0_0_0_0_8983_solr.war__solr__k1kf17/webapp/WEB-INF/lib/

Notez le chemin de destination pas trés conventionnel : c’est le seul endroit ou l’autoload semble capter le jar. Si un expert java passe par là et peut m’expliquer…

Il ne nous reste plus qu’à mettre à jour notre fichier de configuration d’import, et à relancer l’indexation :

<dataConfig>
    <dataSource type="FileDataSource" encoding="UTF-8" />
    <document>
    <entity name="page"
        processor="XPathEntityProcessor"
        stream="true"
        forEach="/mediawiki/page/"
        url="/var/www/solrdemo/dumps/frwiki-latest-pages-articles.xml"
        transformer="RegexTransformer,DateFormatTransformer,WikiTransformer"
        >
        <field column="id"    xpath="/mediawiki/page/id" />
        <field column="title"     xpath="/mediawiki/page/title" />
        <field column="body"      xpath="/mediawiki/page/revision/text" />
        <field column="revision"  xpath="/mediawiki/page/revision/id" />
        <field column="user"      xpath="/mediawiki/page/revision/contributor/username" />
        <field column="userId"    xpath="/mediawiki/page/revision/contributor/id" />
        <field column="timestamp" xpath="/mediawiki/page/revision/timestamp" dateTimeFormat="yyyy-MM-dd'T'hh:mm:ss'Z'" />
        <field column="$skipDoc"  regex="^(?i)#redirect.*" replaceWith="true" sourceColName="body"/>
       </entity>
    </document>
</dataConfig>

Et voilà, vous disposez de votre propre moteur de recherche Wikipedia. Les raffinements possibles sont nombreux, je laisse votre imagination vous guider. En attendant, rendez-vous au prochain SudWeb.

Notes :

1. Pour les francophones acharnés, surbrillance des résultats, mais c’est moche [retour]
2. Notez comme s’extériorise ma haine et ma jalousie envers les gens qui ont la chance de travailler avec un vrai langage de programmation [retour]
3. Allez, avouez, je sais que vous le faites [retour]

photo credit : Thibault Jouannic

Voilà la reprise, les premiers froids, les feuilles qui tombent, la nostalgie des vacances, etc. Mais la rentrée est également pour moi l’opportunité de dépoussiérer un peu mon cerveau et ce blog, avec du temps consacré à l’indispensable… Veille techno. Parce que la veille, c’est comme le sport. Quand on ne pratique pas, on s’encrasse vite. Surtout quand on est freelance.

Bref, dans cet article, nous allons utiliser Solr, excellent moteur de recherche dont je vous ai déjà parlé, et implémenter l’autocomplétion de la recherche.

Solr pour l’autocomplétion, ou sortir la Grosse Bertha pour tuer une mite

Les plus attentifs d’entre vous se demanderont sans doute pourquoi utiliser Solr, puissant moteur de recherche full-text en java, pour une bête autocomplétion. Et effectivement, l’outil serait disproportionné si nous n’étions pas dans un des cas suivants :

1. Vous utilisez déjà Solr pour votre moteur de recherche. Dans ce cas, l’utiliser pour l’autocomplétion ne rajoutera pas une grosse charge  ;
2. Vous souhaitez mettre en place une autocomplétion un peu avancée, avec séparation par facettes, etc  ;

Solr, depuis la version 1.4, propose un nouveau module de recherche : Terms Component. Alors que Solr est généralement utilisé pour effectuer des recherches au niveau d’un document, ce module permet d’accéder au infos au niveau des termes présents dans les champs, permettant de répondre à la requête : « Quels sont les termes présent dans tel(s) champ(s), et à combien de document correspondent-ils ? ».

Par ailleurs, notez que nous allons créer une autocomplétion, et pas une autosuggestion. Pour bien cerner la différence, je vous recommande la lecture de cet excellent article sur les différents types d’assistance à la recherche.

Pour être précis, nous allons construire ça. Ceux qui lisent via un lecteur rss et qui n’auraient pas l’image, vous n’avez qu’à aller sur le site.

Pour les autres, vous remarquerez un bête champ de recherche tout ce qu’il y a de plus classique. L’autocomplétion, en revanche, est un tantinet évoluée, puisqu’elle s’effectue sur deux champs différents. Vous êtes prêts ? C’est parti !

Choisir les bons outils

À l’heure ou j’écris, la version stable de Solr est la 1.4.1. Elle présente toutefois un bug dans le formatage json des résultats. Nous utiliserons donc Solr dans sa version nightly build.

L’autocomplete sera assuré par jQuery, librairie javascript que l’on ne présente plus, et par son trés bon complément jQuery UI.

Notez l’existance d’une trés complète (mais assez complexe) librairie ajax pour Solr. Elle constitue pratiquement un framework à elle toute seule, et pour le coup, nous la laisserons de côté.

Le code ! Le code !

Commençons par le HTML. Ici, rien que du classique.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>
    <script type="text/javascript" src="./js/jquery-1.4.2.min.js"></script>
    <script type="text/javascript" src="./js/jquery-ui-1.8.5.custom.min.js"></script>
    <script type="text/javascript" src="./js/solr.js"></script>
 
    <link rel="stylesheet" type="text/css" media="screen" href="./css/ui-lightness/jquery-ui-1.8.5.custom.css" />
 
  </head>
  <body>
    <form action="" method="get">
      <input type="text" id="search" name="q" />
      <input type="submit" value="Search" />
    </form>
 
    <div id="result">
      <p>Results go here</p>
    </div>
  </body>
</html>

Un banal champ texte, l’inclusion des scripts nécessaires, et c’est tout. Circulez, ya rien à voir !

La configuration Solr n’est pas trés intéressante non plus. J’ai pris la première install de Solr qui m’est passée sous la main. Vous pouvez vous réferer au schema.xml d’un précédent article.

Le seul fichier vraiment intéressant est le javascript :

$(document).ready(function() {
  $('#search').autocomplete({
    source: function(request, response) {
      $.ajax({
        url: 'http://localhost:8983/solr/terms?terms.fl=name',
        dataType: 'jsonp',
        data: {
          wt: 'json',
          'json.nl': 'arrarr',
          'terms.prefix': request.term,
          'terms.sort': 'index',
          'terms.limit': 5,
          omitHeader: 'true'
        },
        jsonp: 'json.wrf',
        success: function(data) {
          response($.map(data.terms.name, function(item) {
            return {
              label: item[0] + ' (' + item[1] + ')',
              value: item[1]
            };
          }));
        }
      })
    }
  });
});

Quelques explications. Dans l’url utilisée par le widget d’autocomplétion, terms.fl désigne le champ qui sera utilisé pour la requête (ici : « name »).

Notez les options « datatype : jsonp », « wt : json », « json.nl : arrarr », « jsonp : wrf ». Elles permettent de faire fonctionner l’appel ajax en cross-domain (via jsonp au lieur de json), et d’obtenir un formatage correct du résultat de la part de Solr.

Enfin, dans le callback « result », nous formattons le résultat en utilisant la fonction $.map de jquery.

Nous avons maintenant un widget de recherche qui réalise une autocomplétion sur le champ « name ». C’est pas mal, mais nous souhaitions une autocomplétion à facette sur différents champs.

L’autocomplétion à facette

Pour ce faire, nous allons modifier deux choses. D’abord, il va falloir définir un template de widget spécifique pour afficher le champ recherché. Ensuite, la fonction qui parse le résultat renvoyé par Solr va devoir prendre en compte les différents champs.

$(document).ready(function() {
 
  // Widget autocomplete spécifique
  // cf. http://jqueryui.com/demos/autocomplete/#categories
  $.widget( "custom.catcomplete", $.ui.autocomplete, {
    _renderMenu: function( ul, items ) {
      var self = this,
        currentCategory = "";
      $.each( items, function( index, item ) {
        if ( item.category != currentCategory ) {
          ul.append( "<li class='ui-autocomplete-category'>" + item.category + "</li>" );
          currentCategory = item.category;
        }
        self._renderItem( ul, item );
      });
    }
  });
 
  $('#search').catcomplete({
    source: function(request, response) {
      $.ajax({
        url: 'http://localhost:8983/solr/terms?terms.fl=name&terms.fl=tag_fr',
        dataType: 'jsonp',
        data: {
          wt: 'json',
          'json.nl': 'arrarr',
          'terms.prefix': request.term,
          'terms.sort': 'index',
          'terms.limit': 5,
          omitHeader: 'true'
        },
        jsonp: 'json.wrf',
        success: function(data) {
 
          answer = new Array();
 
          $.each(data.terms, function(facet, terms) {
            answer = answer.concat($.map(terms, function(item) {
              return {
                label: item[0] + ' (' + item[1] + ')',
                value: item[1],
                category: facet
              };
            }));
          });
          response(answer);
        }
      })
    }
  });
});

Notez l’url utilisée dans le widget autocomplete : il y a maintenant deux options « terms.fl », mais il pourrait y en avoir beaucoup plus.

La fonction d’analyse des résultats est un peu plus complexe. Pour chaque champ renvoyé par solr, elle construit un tableau de termes, en y adjoignant la catégorie, c’est à dire le champ courant. Tous les tableaux sont ensuite concaténés, en renvoyés en réponse.

La catégorie est utilisée par le template de rendu du widget, pour être affichée dans le menu d’autocomplétion.

Dans nos styles, il faudra ajouter ceci :

.ui-autocomplete-category {
  font-weight: bold;
  padding: .2em .4em;
  margin: .8em 0 .2em;
  line-height: 1.5;
}

Et voilà ! Un widget d’autocomplétion un poil moins que basique. Partant de cette base, je vous laisse imaginer les améliorations les plus raffinées. Si vous avez des idées de démo, je suis preneur.

– Edit –

J’ai oublié de mentionner le problème de la sécurité. Bien entendu, c’est une trés mauvaise idée de laisser Solr en accès libre depuis l’extérieur. Donc ou bien vous créez un proxy, ou bien vous créez un requesthandler spécifique en lecture seule. C’est tout.

photo credit : B Tal

Salut la compagnie. Ce billet (vraissemblablement le dernier de l’année) est destiné à faire passer une annonce (et aussi à ramener un peu de traffic, j’avoue).

Si vous n’êtes pas abonné à mon twitter, vous ne savez peut-être pas encore que je viens de lâcher dans la nature un nouveau plugin pour Symfony, qui porte le doux nom de tjSolrDoctrineBehaviorPlugin.

Ce plugin, comme son nom l’indique, permet de coupler trés simplement le framework Symfony et le moteur de recherche Solr. Ainsi, vous pouvez bénéficier dans vos projets Symfony d’un moteur de recherche au top, même si vous n’êtes pas familier avec Solr.

Il s’agit d’une version beta, ce qui signifie que je suis preneur de toutes remarques ou commentaires sur le sujet. Je n’en dit pas plus, la documentation du plugin est suffisamment détaillée comme ça.

C’est tout. Je m’en vais maintenant prendre un repos bien mérité, et déguster de délicieux chaussons aux pommes maison (tout le monde s’en fout, mais j’aime bien qu’on sache que j’apprécie mes vacances).

Bonnes fêtes à tous.

photo credit : Joseph Robertson

Aujourd’hui, je vous propose de poursuivre nos articles sur les technologies de moteur de recherche avec un nouveau tutoriel pour Solr. Au menu : comment mettre en place une recherche à facette. Avec pour démarrer un rappel du principe de la recherche à facette, et ensuite, la config de Solr proprement dite.

Facette ? Késako ?

Commençons par un petit rappel historique (ça donne un côté intellectuel à l’article) : dans la brève mais fulgurante histoire du web, deux paradigmes de recherche se sont principalement imposés :

1. D’abord, la recherche navigationnelle dans une taxonomie^[1] (ex : Dmoz). Le principe est simple : on présente à l’internaute l’intégralité du contenu disponible, trié par catégories, sous-catégories, sous-sous-catégories, etc. et dans lequel il devra naviguer jusqu’à trouver ce qui l’intéresse.

   Ce modèle n’est plus qu’occasionnellement utilisé, car une simple recherche de contenu peut parfois se transformer en véritable expédition spéléologique, apte à décourager même les plus téméraires.

2. Ensuite naquit la recherche directe par requêtes sous formes de mots-clés, qui prit son essort lorsque le Dieu Google démontra qu’il était possible de la mettre en place à l’échelle du web entier. Simple, direct, idéale pour l’internaute pressé qui sait ce qu’il veut.

Chaque méthode présente ses avantages et des inconvénients. La recherche par facette vise à combiner le meilleur des deux mondes. Elle offre à l’utilisateur la possibilité d’affiner une recherche directe en navigant dans une liste de critères contextuels et indépendants.

Un petit dessin vaut mieux qu’un long discours, voici un mini-mockup (réalisé grâce à l’excellent Pencil) qui vous permettra de vous faire une idée d’un coup d’œil.

1. « Écran » représente une facette de recherche.
2. « Bureautique » est un critère qui permet d’appliquer une contrainte pour une facette particulière.
3. Le « 15 » à côté du critère « 500Go » indique combien de résultats correspondent à cette contrainte particulière.
4. Le fil d’ariane permet d’afficher les contraintes déjà appliquées, et de les supprimer.

Le principe est simple : une zone de texte pour les requêtes directes, et en fonction des résultats renvoyés, on présentera à l’internaute différents critères, organisés par facettes, qui lui permettront de raffiner sa recherche en appliquant des contraintes sur les résultats.

Bon, je résume un peu, mais il existe de trés bonnes ressources pour se renseigner sur le principe des recherches à facettes.

Maintenant que la théorie est derrière nous, laissons place à la pratique.

Configurer Solr

Pour l’exemple, comme je n’ai pas envie de travailler sur le sempiternel site de e-commerce, nous allons refondre le moteur du site du célèbre (mais pas trés beau) marmiton.org. Notre moteur renverra donc des recettes en guise de résultats.

La première étape est de décider des critères de recherche que nous allons mettre en place. Ne faites pas comme chez Dell, choisissez-les avec parcimonie, sous peine de voir l’expérience utilisateur se dégrader rapidement.

Voici les critères de recherche que nous allons mettre en place :

Ces critères vont définir la manière dont nous allons indexer nos données. Voici la portion intéressante du schema.xml correspondant.

  <field>
   <field name="id" type="string" indexed="true" stored="true" required="true" /> 
   <field name="nom" type="text" indexed="true" stored="true" required="true" /> 
   <field name="repas" type="string" indexed="true" stored="false"/>
   <field name="plat" type="string" indexed="true" stored="false"/>
   <field name="difficulte" type="string" indexed="true" stored="false"/>
   <field name="prix" type="sfloat" indexed="true" stored="false"/>
   <field name="saison" type="string" indexed="true" stored="false"/>
  </field>

Vous remarquerez la déplorable optimisation des noms et des types des champs, ainsi que l’excessive simplification de la définition du schéma. Cela dit, on s’en fout, c’est juste pour la démo.

Pour les fainéants, voici également quelques données de tests à inclure directement.

<add>
    <doc>
        <field name="id">1</field>
        <field name="nom">Soufflé aux crevettes</field>
        <field name="repas">Dîner</field>
        <field name="plat">Plat principal</field>
        <field name="difficulte">Expérimenté</field>
        <field name="prix">5</field>
        <field name="saison">Automne</field>
        <field name="created_at_dt">2009-01-02T00:00:00.000Z</field>
    </doc>
    <doc>
        <field name="id">2</field>
        <field name="nom">Charlottes aux groseilles</field>
        <field name="repas">Déjeuner</field>
        <field name="plat">Dessert</field>
        <field name="difficulte">Débutant</field>
        <field name="prix">7</field>
        <field name="saison">Été</field>
        <field name="created_at_dt">2009-01-05T00:00:00.000Z</field>
    </doc>
    <doc>
        <field name="id">3</field>
        <field name="nom">Gloubigoulba</field>
        <field name="repas">Petit-déjeuner</field>
        <field name="plat">Plat principal</field>
        <field name="difficulte">Astronomique</field>
        <field name="prix">23492</field>
        <field name="saison">Hiver</field>
        <field name="created_at_dt">2009-02-02T00:00:00.000Z</field>
    </doc>
    <doc>
        <field name="id">4</field>
        <field name="nom">Soupe à la grimace</field>
        <field name="repas">Dîner</field>
        <field name="plat">Entrée</field>
        <field name="difficulte">Expérimenté</field>
        <field name="prix">3</field>
        <field name="saison">Hiver</field>
        <field name="created_at_dt">2009-06-02T00:00:00.000Z</field>
    </doc>
    <doc>
        <field name="id">5</field>
        <field name="nom">Salades de bobards</field>
        <field name="repas">Déjeuner</field>
        <field name="plat">Entrée</field>
        <field name="difficulte">Débutant</field>
        <field name="prix">9</field>
        <field name="saison">Toutes</field>
        <field name="created_at_dt">2009-06-18T00:00:00.000Z</field>
    </doc>
    <doc>
        <field name="id">6</field>
        <field name="nom">Gratin de couleuvres</field>
        <field name="repas">Dîner</field>
        <field name="plat">Plat principal</field>
        <field name="difficulte">Expérimenté</field>
        <field name="prix">2</field>
        <field name="saison">Toutes</field>
        <field name="created_at_dt">2009-09-09T00:00:00.000Z</field>
    </doc>
</add>

Avant toute chose, je vous encourage à tester la bonne indexation des données. C’est bon ? Alors passons à la recherche à facette.

Place aux facettes

Il existe trois types de facettes possibles. Pour vous en convaincre, essayez de rajouter le paramètre facet=true, qui active la recherche par facette.

http://localhost:8983/solr/select?q=*:*&facet=true

Notez l’apparition de nouvelles clés dans l’affichage des résultats.

…
<lst name="facet_counts">
<lst name="facet_queries"/>
<lst name="facet_fields"/>
<lst name="facet_dates"/>
</lst>

Nos trois types sont donc :

• Les facettes par champ (field faceting) : Comptent les résultats en partitionnant selon un champ donné  ;
• Les facettes par requêtes (query faceting) : Comptent les résultats qui correspondent à certaines requêtes  ;
• Les facettes par date (date faceting) : Comptent les résultats en partitionnant selon des intervalles de dates  ;

Commençons par le plus simple, et certainement le plus utilisé : les facettes par champ. Rien de plus simple, il vous suffit d’ajouter le nom du champ dans l’url, grâce au paramètre facet.field, et… et c’est tout. Il est bien entendu possible d’ajouter plusieurs paramètres à la fois, pour autant de facettes.

http://localhost:8983/solr/select?q=*:*&rows=0&facet=true&facet.field=repas&facet.field=saison&facet.field=difficulte

<lst name="facet_counts">
    <lst name="facet_queries"/> 
 
    <lst name="facet_fields">
 
        <lst name="repas">
            <int name="Dîner">3</int>
            <int name="Déjeuner">2</int>
            <int name="Petit-déjeuner">1</int>
        </lst>
 
        <lst name="saison">
            <int name="Hiver">2</int>
            <int name="Toutes">2</int>
            <int name="Automne">1</int>
            <int name="Été">1</int>
        </lst>
 
        <lst name="difficulte">
            <int name="Expérimenté">3</int>
            <int name="Débutant">2</int>
            <int name="Astronomique">1</int>
        </lst>
    </lst>
    <lst name="facet_dates"/>
</lst>

Le résultat affiche maintenant la liste des facettes, avec le nombre de réponses pour chaque paramètre. Vous pensiez que ça allait être compliqué ? Au passage, vous pouvez consulter la liste des paramètres disponibles.

Note : le calcul des facettes s’effectue toujours dans le contexte de la recherche actuelle. Si ma recherche initiale (q=) ne retourne que 3 résultats, seuls ces trois là seront pris en compte.

Les facettes par requêtes

Les facettes par requêtes permettent de spécifier des requêtes (au format classique) plutôt que d’utiliser directement les valeurs des champs. C’est particulièrement utile pour les intervalles (ex : les prix).

Les requêtes sont spécifiées via le champ facet.query. Ajoutez plusieurs requêtes pour plusieurs facettes.

http://localhost:8983/solr/select?q=*:*&rows=0&facet=true&facet.query=prix:[*+TO+5]&facet.query=prix:[5+TO+10]&facet.query=prix:[10+TO+*]

<lst name="facet_counts">
    <lst name="facet_queries">
        <int name="prix:[* TO 5]">3</int>
        <int name="prix:[5 TO 10]">3</int>
        <int name="prix:[10 TO *]">1</int>
    </lst>
    <lst name="facet_fields"/>
    <lst name="facet_dates"/>
</lst>

Les facettes par dates

Il serait bien entendu possible d’obtenir des facettes sur des champs dates en utilisant des requêtes, mais pourquoi se compliquer la vie  ? Grâce aux facettes par date, il suffit d’indiquer une date de début, une date de fin, et un intervalle.

Utile si je veux connaître le nombre de commentaires postés pour chaque heure de la journée, ou le nombre de recettes postées par mois de l’année.

Les paramètres utiles sont :

• facet.date : indique quel sera le champ pris en compte  ;
• facet.date.start : quelle est la date de début de la période prise en compte  ;
• facet.date.end : je vous laisse deviner  ;
• facet.date.gap : l’invervalle de partitionnememt  ;

http://localhost:8983/solr/select?q=*:*&facet=true&facet.date=created_at_dt&facet.date.start=NOW/YEAR&facet.date.end=NOW&facet.date.gap=+1MONTH

NOW/YEAR signifie que je démarre mon calcul du début de l’année. La syntaxe est relativement simple, je vous laisse consulter la doc.

Sélectionner un critère

photo credit : Ryan Orr

Avec tout ça, vous êtes désormais capables d’effectuer des recherches par facettes sur des requêtes de bases. Il nous reste à voir comment restreindre notre recherche en sélectionnant un critère particulier. Pour ce faire, nous allons utiliser le paramètre fq (pour filter query), qui nous permettra d’appliquer un filtre sur les résultats renvoyés par la requête initiale.

Pour l’exemple, reprenons notre requête initiale, avec facettes sur divers champs de la recette.

http://localhost:8983/solr/select?q=*:*&rows=0&facet=true&facet.field=repas&facet.field=saison&facet.field=difficulte

Admettons que je cherche une idée de recette pour le repas de noël, je vais restreindre ma recherche en n’affichant que les plats réalisables en hiver.

http://localhost:8983/solr/select?q=*:*&facet=true&facet.field=repas&facet.field=difficulte&fq=saison:Hiver

J’applique donc mon filtre (fq:Hiver), et j’en profite pour supprimer la facette sur le champ « saison » qui ne sert plus à rien. Rien ne m’empêche de raffiner ma requête selon plusieurs critères en utilisant plusieurs fois le paramètre fq.

Vous savez tout. Il ne reste plus qu’à gérer tous ces paramètres côté frontend, en affichant le fil d’ariane, les critères et les effets kikoolol qui vont bien.

Notes :

1. Admirez au passage le savant emploi de mots techniques qui n’a d’autres utilité que de me donner l’air d’être un expert [retour]

photo credit : h.koppdelaney

C’est un petit pas pour l’humanité, mais un grand saut pour moi. À partir de décembre, je serai inéluctablement freelance à plein temps.

Fini les embouteillages tous les matins (même si je prends le vélo, ça n’empêche pas l’air de puer le gaz). Envolés, les 2.5 jours de congés par mois. Me voilà pleinement maître de mon destin, et ça fait du bien (Ah ?! On me signale que les freelances n’ont pas la vie rose tous les jours ? Bon, tant pis…)

J’aurais pu me qualifier d’« entrepreneur », de « chef d’entreprise », d’« indépendant », voire d’« indep’ », mais j’aime cette image du chevalier, libre comme l’air et cheveux au vent, n’ayant pour biens que sa monture et son épée (une lance, en l’occurence), chevauchant par monts et par vaux en combattant pour ses idéaux, et aussi un peu pour remplir sa gamelle.

Alors voilà, puisque vous me le demandez (sisi, vous me le demandez), j’ai choisi, dans un premier temps, de focaliser mon activité sur les développements web spécifiques, basés sur l’intégration des technologies libres suivantes :

• Symfony : Le top des frameworks PHP, pour des développements spécifiques fonctionnels et standardisés  ;
• eZ Publish : La Rolls Royce des CMS, pour des sites éditoriaux haut de gamme  ;
• Solr : Le meilleur moteur de recherche libre au monde, pour fournir à vos utilisateurs une expérience de recherche incomparable  ;

Et puis, tant qu’à faire, j’entends bien batir des prestations de qualité, en industrialisant mes développements au maximum (TDD, intégration continue, méthodo agile, etc.).

Je serai bien entendu enchanté de répondre à votre coup de fil si vous souhaitez discuter de votre projet. Si vous voulez en savoir plus, vous pouvez consulter ma page professionnelle. Vous y trouverez les informations nécessaires pour me contacter.

Comme je suis d’un naturel optimiste, je suis intimement convaincu que tout ce passera bien et que j’adorerai ma nouvelle vie. Cela dit, un petit commentaire d’encouragement est toujours bon à prendre