> The QueryParser then adds the -- parsing -- on top of this, but can delegate for query delegation.
That sould be "query creation", of course. > -----Original Message----- > From: Irving, Dave [mailto:[EMAIL PROTECTED] > Sent: 23 May 2006 08:30 > To: java-user@lucene.apache.org > Subject: RE: Searching API: QueryParser vs Programatic queries > > Chris Hostetter wrote: > > > typically, when build queries up from form data, each piece of data > > falls into one of 2 categories: > > > > 1) data which doesn't need analyzed because the field > it's going to > > query on wasn't tokenized (ie: a date field, or a > numeric field, > > or a > > boolean field) > > But couldn't even these simple field types also need analysing? > E.g, I could have a very simple number field - so I need to > pad it at both index and search time to a certain number of > characters. Isn't a custom TokenFilter added to an analyser a > reasonable way to handle such fields (keeping the logic of > how to transform input into Term all in one place). > > > 2) data whcih is typed by the user in a text box, and not > only needs > > analyzed, but may also need some parsing (ie: to > support "quoted > > phrases" or +mandatory and -prohibited terms) > > > > in the first case, build your query clauses progromatically. > > > > in the second case make a QueryParser on the fly with the > defaultField > > set to whatever makes sense and let it handle parsing the > users text > > (and applying hte correct analyzer using PerFieldAnalyzer. > if there > > are special characters you want it to ignore, then escape > them first. > > Yeah, one of my fields is "keywords" - in to which the user > can type a list of terms - all of which need to be analysed. > It seems all I logically want to do is extract the terms from > the input > - running each through an analyser - and then combining them > in to a boolean query. > However, a typical search will be "C++" - so Im also going to > have to escape the content - because Im using a QueryParser. > > I certainly agree that I can accomplish what I want by > escaping, running thru the query parser and combining using > boolean queries. > > I think the query factory patch (LUCENE-344) is pretty close > to what I was trying to get at. > The ability to say the following would be really cool: > > Query keywordsQuery = queryFactory.getFieldQuery("keywords", > someAnalyser, keyworkdsText); > > The factory lets us get to the guts of running the content > through the analyser, and extracting a query in various ways > - without having to do extra work (escaping, overriding > unsupported methods) so that we can achieve the same goal > with the Query Parser. Seems like a nice Separation of Concerns. > > The QueryParser then adds the -- parsing -- on top of this, > but can delegate for query delegation. > > > i discussed this a little more recently... > > > > http://www.nabble.com/RE%3A+Building+queries-t1635907.html#a4436416 > > > > Indeed. I apologise - I should have stuck with that original thread. > Sorry for the carelessness. > > > > > -Hoss > > > > 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]
