I'm working on designing this kind of meta configuration on top of some Lucene
indexes right now. The company I work for has several different "products"
which have to be indexed and searched, each with their own field list.
Sometimes products will map to many individual Lucene indexes.
The structure I've come up with works via xml configuration files (read and
written using digester). I have entities for field meta data which are
aggregated into a FieldMap object. Each product can have one or more FieldMaps
which are used during parsing and indexing for each indexable unit that is
processed.
I am then grouping multiple products together into a "Search Application" - I
want to build multisearchers for each of these, plus a load of filters to
support narrowing down of query criteria based on the users input on the search
form.
At a later stage, will build a web admin console which will let administrators
edit and create new products, applications, fields etc. Not sure if I can also
use the LIMO libraries for some index monitoring within the app too.
We intend to build our own version of a query parser to allow finer control -
especially in as regards the toomanylcauses exception.
Hope this gives you some ideas, Dave.
Marc
----- Original Message ----
From: Erik Hatcher <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Wednesday, 17 May, 2006 2:42:04 PM
Subject: Re: Building queries
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
