[sdx-developers] Pour une API de recherche "universelle"

[Pierrick Brihaye]

Bonjour,

Comme suggéré dans sdx-users, je passe cette conversation dans la 
présente liste.

Voilà : l'un des grands revers de SDXSimpleQuery est d'*analyser* la 
requête qui lui est passée. Cela est très pratique si tous les index 
étaient analysés de la même façon, malheureusement, cela n'est pas 
toujours le cas... et ça risque de le devenir de moins en moins dans un 
environnement multilingue.

Or, les index de type "field" ne sont pas tokenisés et donc pas analysés 
(je n'ai d'ailleurs pas encore vu où cela se passe, mais bon...) puisque 
l'analyse vise justement à renvoyer des tokens ;-).

Je crois ne pas me tromper en disant que le langage de requête 
"standard" de SDX (de Lucene en fait) semble avoir un défaut de conception.

En effet :

champ:debutvaleur finvaleur

est perçu comme :

champ:debutvaleur champ_par_défaut:finvaleur.

Quand bien même le contexte d'interrogation d'un index serait maintenu 
(par quel procédé ?), la requête Lucene serait traitée comme :

champ:debutvaleur OR champ:finvaleur

car, en l'absence d'opérateur, c'est un "OU" qui est implicite.

Or, si "champ" est de type "field", l'utilisateur recherchera probablement :

champ:'debutvaleur finvaleur' (les quotes simples ne font évidemment pas 
partie du langage de requête)

l'espace étant *partie intégrante* de la dite valeur...

Je me demande donc s'il ne faut pas proposer une syntaxe qui permettrait 
 d'interroger ces valeurs litérales qui peuvent éventuellement contenir 
des valeurs contenant les séparateurs standard de lucene :

espace
||
OR (qui a pourtant toute son utilité dans une base de données 
francophone d'orfèvrerie ;-)
AND
+
!
-
NOT
guillemets (recherche de citations par exemple)

Le quote simple a le désavantage de se confondre avec l'apostrophe, 
quoiqu'une apostrophe débute et termine rarement une phrase... sauf en 
néerlandais (je crois) : "'t" pour "het" article du neutre...

J'ajoute que l'on pourrait également prévoir une syntaxe pour les 
intervalles de dates (le tiret pourrait faire l'affaire s'il ne se 
confondait avec le "-" de Lucene).

A partir de là, on pourrait concevoir d'écrire un parseur spécifique 
capable d'envoyer autant de fieldQuery (ou de exactFieldQuery) que 
nécessaire, les dites query étant savamment combinées en booleanQuery...

Qu'en pensez-vous ?

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden