It must be time to eat lunch, since the more I stare at this code, the less
sense it makes to me. Which is a sure sign that I need a break .
But a couple of things.
1> my test cases throw some exceptions with the code as-is. The spans.get(0)
is a problem in that it's not guaranteed that the
1> my test cases throw some exceptions with the code as-is. The
spans.get(0)
is a problem in that it's not guaranteed that the spans returned will
have
anything in them. Also, I don't think that the test for
reqSpans.get(0).next
in queryClauses[i].isRequired is correct (even if it doesn't th
That may be the difference then. I'm actually working with both a complete
index and a memory index, depending on what phase I'm in. It turns out that
I probably can't put the document in a memoryindex on the fly
because...well...because ... That said, though, I can pretty easily use
this as a bas
The following addresses the reuse of the Spans object and fixes a bug in
checking for required clauses (boolean test was reversed). Again, the
only testing I have done involves one doc for "real" hit highlighting so
your mileage may vary. Attempt number two:
import org.apache.lucene.index.Ind
> hello,
>
> I have a problem with the QueryParser and the default search operator
> AND.
>
> So let me please explain my problem in hope that you can help me.
>
> I have integrated the search engine in our CRM product. To make it
> easier for the user we decided to set the default search oper
Using the lucene API, is there a way to copy the contents and
parameters of fields between documents in different indexes? Without
requiring the field to be stored or needing to pass around the
fulltext contents of the field.
I guess I am looking for
doc.add(new Field("contentsNew", copyFr
On Feb 15, 2007, at 1:20 PM, Yonik Seeley wrote:
I originally added it without an Index param at all.
I can't say I'm a fan of the way Field currently does things, and I
didn't want everyone to pay the price for yet more options.
Solved... with fixed field definitions.
http://www.rectangular
On 2/16/07, Marvin Humphrey <[EMAIL PROTECTED]> wrote:
Solved... with fixed field definitions.
<>
Imagine a world with no search-time/index-time analyzer mismatches...
I'm sure Yonik can imagine such a world... that's what Solr provide
. Configure an analyzer for a field (or even separate
On Feb 16, 2007, at 1:53 PM, Karimi-Tabatabaie Jamal wrote:
For my problem there seems to exist a lucence Bug
(http://issues.apache.org/jira/browse/LUCENE-167) but also it seems
that
it's solved in the Lucene integration on site http://
www.lucenebook.com.
Where do you see the problem solve
