Hi Otis, Thanks for your reply. Yeah, Im aware of PerFieldAnalyserWrapper - and I think it could help in the solution - but not on its own. Here's what I mean:
When we build a document Field, we suppy either a String or a Reader. The framework takes care of running the contents through an Analyser (per field or otherwise) when we add the document to an index. However, on the searching side of things, we don't have similar functionality unless we use the QueryParser. If we build queries programatically, then we have to make sure (by hand) that we run search terms through the appropriate analyser whilst constructing the query. Its in this area that I wonder whether additional utility classes could make programatic construction of queries somewhat easier. Dave > -----Original Message----- > From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] > Sent: 22 May 2006 15:59 > To: java-user@lucene.apache.org > Subject: Re: Searching API: QueryParser vs Programatic queries > > Dave, > You said you are new to Lucene and you didn't mention this > class explicitly, so you may not be aware of it yet: > PerFieldAnalyzerWrapper. > It sounds like this may be what you are after. > > Otis > > ----- Original Message ---- > From: "Irving, Dave" <[EMAIL PROTECTED]> > To: java-user@lucene.apache.org > Sent: Monday, May 22, 2006 5:15:23 AM > Subject: Searching API: QueryParser vs Programatic queries > > Hi, > > Im very new to Lucene - so sorry if my question seems pretty dumb. > > In the application Im writing, I've been "struggling with > myself" over whether I should be building up queries > programatically, or using the Query Parser. > > My searchable fields are driven by meta-data, and I only want > to support a few query types. It seems "cleaner" to build the > queries up programatically rather than converting the query > to a string and throwing it through the QueryParser. > > However, then we hit the problem that the QueryParser takes > care of Analysing the search strings - so to do this we'd > have to write some utility stuff to perform the analysis as > we're building up the queries / terms. > > And then I think "might as well just use the QueryParser!". > > So here's what Im wondering (which probably sounds very dumb > to experienced Lucene'rs): > > - Is there maybe some room for more utility classes in Lucene > which make this easier? E.g: When building up a document, we > don't have to worry about running content through an analyser > - but unless we use QueryParser, there doesn't seem to be > corresponding behaviour on the search side. > - So, Im thinking some kind of factory / builder or > something, where you can register an Analyser (possibly a per > field wrapper), and then it is applied per field as the query > is being built up programatically. > > Maybe this is just an "extraction" refactoring to take this > behaviour out of QueryParser (which could delegate to it). > > The result could be that more users opt for a programatic > build up of queries (because it's become easier to do..) > rather than falling back on QueryParser in cases where it may > not be the best choice. > > > Sorry if I rambled too much :o) > > Dave > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
