Searching on Multiple fields

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Searching on Multiple fields

Rod.Madden
Currently, my Lucene search code allows the user to specify
which fields are searched ...I have now had a request to enhance
the code to allow the users to specify that certain
searchfields contain one value and other ( or all other ) fields
contain a different value.
 
In Luke I can do following to run this type of search:
 +secondarySection:"Vendor Information" +title:types
 

The relevant section of my code as it currently stands is
as follows: ...
.
.
.
// Is a Lucene FSDir object available
if (fsDir != null) {
    is = new IndexSearcher(fsDir);
    // searchFields are those Lucene fields which I need to search for
the search term
    qp = new MultiFieldQueryParser(searchFields,new StopAnalyzer());
 
    if (qp != null) {
        // stringToFind is search term I am searching for across all
fields
       query = qp.parse(stringToFind.toUpperCase());
    } // if ( fsDir != null )
}
 
Can anyone suggest how I need to proceed to mod this code to allow for
the new feature requested ...
 
Thanks
 
 
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Searching on Multiple fields

Erick Erickson
You could always construct a BooleanQuery with all the necessary sub-clauses
on an as-needed basis. You can string the sub-clauses together in
arbitrarily complex ways. Be particularly aware that you one of the clauses
of a BooleanQuery may itself be a boolean query, so constructing something
like 'a and (b or c)' is equivalent to (fast pseudo code with parameters and
lotsa other stuff left out here)

BooleanQuery bqSub;
bqSub.add("b", SHOULD);
bqSub.add("c", SHOULD);

BooleanQuery bqTop;
bq.add(bqSub, MUST);
bq.add("a", MUST);

etc, etc, etc...

Best
Erick
Reply | Threaded
Open this post in threaded view
|

Hits syncronization

Mark Miller-3
In reply to this post by Rod.Madden
Does the Hits class need to use a Vector for it's cache? Is the cache
somehow shared among threads or should this be an ArrayList to avoid
synchronization costs? Also, I do not see any backing array size
initialization. Is this because the default of 10 is optimal? Am I wrong
all over the place?

- mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Hits syncronization

Karl Wettin
On 7/16/06, Mark Miller <[hidden email]> wrote:
> Does the Hits class need to use a Vector for it's cache? Is the cache
> somehow shared among threads or should this be an ArrayList to avoid
> synchronization costs? Also, I do not see any backing array size
> initialization. Is this because the default of 10 is optimal? Am I wrong
> all over the place?

The Vector in Hits (Document, RAMDirectory and many more places) are
artifacts from the early days of Lucene (and Java). There has been
some discussion on if they should be replaced or not, but never got
anywhere.

You can safely change it to a JCF-list of your preference.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]