2009-01-22 11 views
3

Si la requête de recherche contient un caractère générique (* ou ?), la fonction de ParseQueryParser renvoie une erreur.caractère générique lance erreur dans Lucene.NET

Dim q As String = "*abc" 
Dim qp As New QueryParser("text", New StandardAnalyzer()) 
Dim query As Query = qp.Parse(q) 

Est-il possible de résoudre ce problème dans Lucene.NET v2.0.0.4?

+0

Il existe plusieurs manières différentes de gérer ce type de requêtes. Je suggère que les requêtes génériques sont généralement une "mauvaise chose". Si vous pouviez donner un peu plus de contexte? Nombre de docs; nombre de champs par doc; taille approximative des champs de texte; Essaies-tu de trouver la fin des mots? est-ce un suffixe commun? sont les termes "codes" ou mots du texte normal ... toute autre information aiderait – AndyPook

Répondre

1

Peut-être que vous devez utiliser un WildcardQuery, mais

... Afin d'éviter extrêmement lent WildcardQueries, un terme Wildcard ne doit pas commencer par un des wildcards ...

5

Définissez QueryParser.SetAllowLeadingWildcard Method sur true. La page de l'API indique que "cela peut produire des requêtes très lentes sur les gros index".

+0

Une mauvaise idée. Bien que cela puisse "fonctionner", il sera très lent, d'autant plus que l'index s'agrandit. Utilisez quelque chose comme le NGramAnalyzer de Contrib (mentionné dans une autre réponse) – AndyPook

+0

@AndyPook Ma réponse est valide sur le plan de la correction, et j'ai mentionné le problème de performance potentiel dans ma réponse. ** Est-ce que ** ça sera "très lent" au point d'être un deal-breaker pour OP? Aucun d'entre nous ne le sait, car la question n'inclut pas suffisamment de détails (par exemple, la taille de l'index, qu'il s'agisse d'une requête unique ou récurrente). En outre, l'approche NGram a ses propres limites (par exemple, OP doit être capable de changer l'index pour utiliser NGram) et des inconvénients (par exemple, l'index peut devenir plus grand car il y a plus de termes). –

+0

Si vous avez raison, cela fonctionnera. Mais la perf se dégradera assez rapidement car elle doit examiner * chaque * terme dans ce domaine. Bien sûr, avec ngram, la taille de l'index peut augmenter (un peu) tel est le chemin des magasins de données. L'ajout d'un index à une base de données SQL ajoute de la taille mais évite les analyses de table. Vous avez également raison de dire que nous ne connaissons pas grand-chose au scénario spécifique à OP. Demandons ... – AndyPook

0

Vous pouvez éviter les requêtes génériques en utilisant NGramFilter pour votre analyseur d'index. Que vous devez utiliser search_analyzer sans NGramFilter. De cette façon, vous pouvez rechercher similaire à like "%text%" sans même avoir besoin de caractères génériques. Vous venez d'entrer 'abc' et votre index sera recherché très rapidement pour toutes les entrées contenant 'abc'.

+0

Les bits NGram se trouvent dans le projet Contrib – AndyPook