On May 17, 2006, at 8:19 AM, Irving, Dave wrote:
First - thanks for Lucene! I started working with it a few days ago,
bought the Lucene In Action book, and Im very impressed with both.
Thank you for the latter! For the former, thanks go to Doug and many
others.
Im integrating search in to an existing pet-project web application
where new fields for index / search may be added via configuration.
My idea is to have a simple FieldMetaData concept which provides
info on
the type of data, the analyzer (if any) used for the field, boosts
etc.
This would allow both the indexing front end and the search front
end to
be driven by this meta-data.
This led me to two questions:
1) Are there any "best / common practises" for this that I've missed
during my web searches and reading of Lucene in Action?
The case studies chapter has some examples of metadata driven
configuration as in TheServerSide section. There aren't any "best
practices" in this regard. Every environment has a different way to
configure it some via JNDI, some via deployment descriptors, most
probably hard-coded, some via .properties files, some via Ant build
files (see contrib/ant), and so on. Solr and Nutch are projects that
leverage Lucene underneath and add a layer of configurability on top
- you can check out how they've done this.
2) I don't want to release the full query syntax to users: So I'll
probably have multiple fields in the UI, and then construct them in
to a
query at the server side. One thing that is mentioned quite a bit in
docs is that the same analyser needs to be used when querying as was
used when indexing. Im guessing my FieldMetaData concept will help
a bit
here - as I'll be able to track the analyser type employed for a
field.
So, I just need to run the terms entered by the user in each field
against the appropriate analyser, and build up the query that way.
Does
that sound like a sensible approach? Are there any code samples around
showing how to run search phrases through analysers and build up a
query?
Yup, as mentioned earlier, PerFieldAnalyzerWrapper is handy in this
scenario.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
