> You need to parse a query string without using query parser and > construct the query and still want an analyzer applied on the outcome search
Not quite. The user is presented with a list of (UI) fields, and each field already knows whether its an "OR" "AND" etc. So, there is no query String as such. For this reason, it seems to make more sense to build the query up programmatically - as my field meta data can drive this. However, if I do that, I have to do the work of extracting terms by running through an analyser for each field manually. This is also done by the query parser. So, right now, if Im being lazy, the easiest thing to do is construct a query string based on the meta data, and then run that through the query parser. This just doesn't -- feel right -- from a design perspective though :o) The logic I could see being extracted out would be some of the stuff in QueryParser#getFieldQuery(String field, String queryText). > -----Original Message----- > From: Raghavendra Prabhu [mailto:[EMAIL PROTECTED] > Sent: 22 May 2006 16:17 > To: java-user@lucene.apache.org > Subject: Re: Searching API: QueryParser vs Programatic queries > > If i understand correctly, is it that you dont want to make > use of query parse? > > You need to parse a query string without using query parser > and construct the query and still want an analyzer applied on > the outcome search. > > > On 5/22/0 p6, Irving, Dave <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
