[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sdx-developers] Recherhes composites
From: |
Pierrick Brihaye |
Subject: |
Re: [sdx-developers] Recherhes composites |
Date: |
Fri, 03 Sep 2004 10:00:26 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.6) Gecko/20040113 |
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