search

adeppathondur / luke

Automatically exported from code.google.com/p/luke
0 stars 0 forks source link

Enhancement #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Attached is a patch which allows custom XMLQueryParser configurations to be
loaded.
A new command-line Luke parameter can pass in the class name of a factory
class used for creating XMLQueryParsers.

Original issue reported on code.google.com by MarkHarw...@gmail.com on 16 Mar 2010 at 4:09

Attachments:

GoogleCodeExporter commented 9 years ago 
Hmm ... I'm not convinced about the usefulness of introducing the factory 
interface
if we don't ship any actual factories .. seems like an overkill.

Original comment by sig...@gmail.com on 16 Mar 2010 at 4:31

GoogleCodeExporter commented 9 years ago 
The XMLQueryParser is a modular parser made up of multiple pluggable "builders" 
and
is deliberately designed to be extended. The upcoming Lucene In Action 2 
includes a
section I wrote on how to do precisely this.

The first thing I wanted to do when I saw this new Luke feature was use my XML 
parser
extension that adds all of my custom XML query tags.

Without this patch Luke precludes any custom XML syntax.

Original comment by MarkHarw...@gmail.com on 16 Mar 2010 at 5:25

GoogleCodeExporter commented 9 years ago 
I see. Can you perhaps modify the patch to at least include two factories out 
of the
box, namely one for CoreParser and the other for CorePlusExtensionsParser?

Original comment by sig...@gmail.com on 17 Mar 2010 at 10:22

GoogleCodeExporter commented 9 years ago 
OK. See attached new patch with additional change to XML parser construction.
I think it was a mistake to instantiate the XML parser with a pre-configured 
Lucene
QueryParser because XML syntax can have more than one <UserQuery> tag and the 
XML
syntax supports different "fieldName" attributes in the tag. These field choices
cannot be honoured if the XML parser is using a pre-configured Lucene 
QueryParser
object because that does not support changing the choice of default field.

Instead, the XMLQueryParser should instantiate Lucene QueryParsers on-demand 
because
a) It can support xml-defined choice of default field at query-time and
b) it doesn't have to synchronize all search requests around a single 
non-thread-safe
object.

The upshot of all of which means that the existing Lucene QueryParser settings 
in the
Luke gui (leading wildcards etc) do not relate to the XML Query parser (maybe I 
have
>1 field which require different lucene parser settings?) Also, surely the 
"default
field" choice has meaning only to Lucene Query parser not the Analyzer?

Incidentally, I now have a custom Analyzer that, given a directory name in the
"optional constructor argument" will read all my per-field-analyzer settings 
which
are serialized in a proprietary XML file next to the index and load all the
appropriate per-field settings. For me this is neat. I can imagine it would be
possible to have a similar Solr-specific equivalent Analyzer which could load 
the
Solr analyzer settings from a given reference to a Solr config.

Cheers
Mark

Original comment by MarkHarw...@gmail.com on 17 Mar 2010 at 12:40

Attachments:

GoogleCodeExporter commented 9 years ago 
I modified slightly this patch, and applied it in rev. 32. Thanks!

Original comment by sig...@gmail.com on 31 Mar 2010 at 4:48

GoogleCodeExporter commented 9 years ago

Original comment by sig...@gmail.com on 31 Mar 2010 at 4:48

GoogleCodeExporter commented 9 years ago 
Many thanks.

Original comment by MarkHarw...@gmail.com on 1 Apr 2010 at 7:04