Giter Club home page Giter Club logo

Comments (7)

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
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 [email protected] on 16 Mar 2010 at 4:31

  • Added labels: ****
  • Removed labels: ****

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
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 [email protected] on 16 Mar 2010 at 5:25

  • Added labels: ****
  • Removed labels: ****

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
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 [email protected] on 17 Mar 2010 at 10:22

  • Added labels: ****
  • Removed labels: ****

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
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 [email protected] on 17 Mar 2010 at 12:40

  • Added labels: ****
  • Removed labels: ****

Attachments:

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
I modified slightly this patch, and applied it in rev. 32. Thanks!

Original comment by [email protected] on 31 Mar 2010 at 4:48

  • Added labels: ****
  • Removed labels: ****

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024

Original comment by [email protected] on 31 Mar 2010 at 4:48

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

from luke.

GoogleCodeExporter avatar GoogleCodeExporter commented on June 28, 2024
Many thanks. 

Original comment by [email protected] on 1 Apr 2010 at 7:04

  • Added labels: ****
  • Removed labels: ****

from luke.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.