Re: Implementing filtering based on multiple fields

Why not just add custom terms onto the end of each query for each user? i.e. When user X queries for "bananas", and has previously set their domains to search in cnn, and yahoo, then why not append the following onto the search query: "fullText:bananas AND (domain:cnn OR domain:yahoo)" Off the

Re: Searching on plurals and phrases in a single field

on "red plentiful"~2, it would fail because > you'd have fox$ and foxes each taking up one position. But if > fox$ and foxes both have the same position, it'll work. > > And it's all in the same index, one field, etc. > > Hope this helps > Erick >

Searching on plurals and phrases in a single field

Hi, We've got a requirement that we need to give our users the ability to search on exact phrases within a field, or, if they prefer, they can match on plurals(either via stems, or another plural algorithm). However, the cases are mutually exclusive, for example given the following field in the

Obtaining the number of segments in an index?

Hi, Is there a way to get the number of segments in an index? I looked at the API's for the reader, writer and searcher, but didn't find anything. Thanks, Lucifer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional comma

IndexReader.deleteDocument(int docid) equivalent in 2.1 IndexWriter?

I noticed that the API for Lucene 2.1+ includes a deleteDocuments(Term) method in the IndexWriter. I'd love to be able to change my application to use it (we're constantly updating docs, which means opening/closing the writer/reader each time we update a doc). I use complex queries to determine w

Re: Backwards index format compatibility of future versions?

On 4/23/07, karl wettin <[EMAIL PROTECTED]> wrote: 23 apr 2007 kl. 06.39 skrev Lucifer Hammer: I'm curious, why is migrating the index not OK when it is OK to upgrade the software? It doesn't really add up in my head. We keep our indexed archives on write-once media. If

Re: Backwards index format compatibility of future versions?

d/search them from future versions of Lucene. Thanks Lucifer On 4/23/07, karl wettin <[EMAIL PROTECTED]> wrote: 23 apr 2007 kl. 06.10 skrev Lucifer Hammer: > Should/can we expect that all future versions of Lucene will be > able to read > older indexes? Yes. <http://

Backwards index format compatibility of future versions?

Hi, Is there a goal for lucene to always be able to read indexes written by older versions of Lucene? For instance, I noticed that I could read 2.0 and 1.9 indexes with a 2.1 Lucene jar. (I also noticed that if I add a document to one of those older indexes, then they'll be rewritten in 2.1 for

Re: Another problem with the QueryParser

Hi Chris, Thanks for your response. If it's alright with you, I'd like to spell it out, just so you can confirm that I'm understanding what you're saying: Here's the Query: "Table OR NOT Chair" I thought the results I should expect are: All documents in the index that have the word "Table"

Another problem with the QueryParser

Hi, I posted a few weeks ago with an issue that revolved around parens in a query. Since then, we've been testing other booleans and came across this anomaly. The test code is almost the same, I'm just modifying the queries. Before I enter it as a bug, I wanted to run it by this group to see if

Suspected problem in the QueryParser

Hi, I recently stumbled across what I think might be a bug in the QueryParser. Before I enter it as a bug, I wanted to run it by this group to see if I'm just not looking at the boolean expression correctly. Here's the issue: I created an index with 5 documents, all have one field: "text", with