Hey - thanks Marc - that's really useful information, thanks so much! Its really good to hear that someone has already used the "field metadata" approach - and I definitely think it's the route I'll now be taking :o)
Thanks, Dave > -----Original Message----- > From: Marc Dauncey [mailto:[EMAIL PROTECTED] > Sent: 17 May 2006 15:00 > To: java-user@lucene.apache.org > Subject: Re: Building queries > > 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] > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
