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]
