Re: [sdx-developers] Recherhes composites

[Pierrick Brihaye]

Salut,

Martin Sevigny a écrit :

> > Au-delà de ça, SDX propose une très intéressante ComplexQuery pour 
> > effectuer diverses recherches et agréger les résultats dans un tout 
> > cohérent : les Results Lucene, capables d'aller chercher les champs 
> > brief.
>
> Oui... mais je crois que l'agrégation va (malheureusement) plus loin :
> jusque dans la requête!

¡ inferno y damnacion !

> > Sans vouloir faire exploser la stratégique LuceneDocumentBase, je me 
> > demande dans quelle mesure on pourrait injecter autre chose qu'une 
> > Query Lucene dans une ComplexQuery.
>
> L'objectif est intéressant, rien à redire.

Il va de soit qu'on peut aller très loin là dedans et, a priori, confier 
tout ça à un "méta" QueryParser :

lucene[field:value] AND SQL[select_clause] OR 
xml-db[/root/address@hidden

Bon OK, il y aura sans doute intérêt à mettre un optimiseur de requête 
avant de lancer tout ça... autant dire du très compliqué.

> D'accord, mais si je ne me trompe pas, une ComplexQuery, peu importe le
> nombre de composantes et leur nature (pour l'instant), se transforme en
> une requête Lucene, qui est exécutée.

¡ Carai !

Note : comme vous l'avez remarqué, je viens de relire Barbe-Rouge :-)

> Donc si on veut avoir des composantes non Lucene dans une ComplexQuery,
> il faut complètement revoir cette approche, et travailler l'agrégation
> au niveau des résultats, et non au niveau des requêtes.

Oui, c'est en gros ce que j'évoquais...

> > recenser la connexion JDBC vers les source de données SQL. Quel est, à 
> > votre avis, le meilleur endroit pour le faire ?
>
> Pour l'instant, on travaille toujours avec des "datasources" déclarées
> dans cocoon.xconf. C'est pas trop compliqué de les récupérer par la
> suite, via le manager de Cocoon.

J'en attendais confirmation :-)

> Je ne sais pas... Mais en fait, à bien y penser, tu veux un lien fort
> entre tes SQLQuery et des index Lucene,

Avec un seul objectif... ramener les "brief".

> alors il faudrait peut-être
> implémenter les SQLQuery au niveau de Lucene (ie une sous-classe de
> Query de Lucene)? Dans ce cas, ça agirait au niveau des Hits je suppose.

C'est l'approche "simple" vs. l'approche évoquée ci-dessus pour laquelle 
le prix à payer est beaucoup plus élevé (construire des jeux de 
résultats intermédiaires et les agréger).

> Mais même ça je ne suis pas certain que ça marcherait. Une ComplexQuery
> (SDX) = une BooleanQuery (Lucene), et je n'ai jamais regardé comment
> était exécutée une BooleanQuery...

Le truc est bien là. Il faudrait avoir 2 types de booleanClause : une 
"vraie" et une "fausse". La fausse singerait (mimic) la vraie en ayant 
son propre Searcher qui serait un SQLSearcher (vs. l'IndexSearcher qui 
attaque un index Lucene). Il faudrait probablement adopter la même 
attitude pour le Scorer et, sans doute, d'autres subtilités luceniennes.

Ca ne s'annonce pas terrible. Hits est concret et... final. Incorrigibles !

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78