My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 12: Enhancement
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Mar 2010

Sign in to add a comment
Reported by, Mar 16, 2010
Attached is a patch which allows custom XMLQueryParser configurations to be
A new command-line Luke parameter can pass in the class name of a factory
class used for creating XMLQueryParsers.

4.5 KB   View   Download
Mar 16, 2010
Project Member #1
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.
Mar 16, 2010
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.

Mar 17, 2010
Project Member #3
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? 
Mar 17, 2010
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

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.


5.9 KB   View   Download
Mar 31, 2010
Project Member #5
I modified slightly this patch, and applied it in rev. 32. Thanks!
Mar 31, 2010
Project Member #6
(No comment was entered for this change.)
Status: Fixed
Apr 1, 2010
Many thanks. 
Sign in to add a comment

Powered by Google Project Hosting