That would work. Though your custom TopSpansCollector should be able to
handle other Scorers as well. And you can store the payloads in yet another
custom ScoreDoc - is that what you had in mind?
Shai
On Sat, Aug 8, 2009 at 3:06 AM, Grant Ingersoll wrote:
>
> On Aug 6, 2009, at 5:09 PM, Grant I
[
https://issues.apache.org/jira/browse/LUCENE-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740859#action_12740859
]
Michael McCandless commented on LUCENE-1781:
OK the new normLat looks like it
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740861#action_12740861
]
Michael McCandless commented on LUCENE-1768:
Given the complexity of customizi
[
https://issues.apache.org/jira/browse/LUCENE-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740865#action_12740865
]
Michael McCandless commented on LUCENE-1784:
I'm a little nervous in general a
[
https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740866#action_12740866
]
Michael McCandless commented on LUCENE-1689:
{quote}
I think instead of the wa
I see this when I run the new QP's unit tests:
[junit] WARN: Message with key:INVALID_SYNTAX and locale: en_US not found.
[junit] WARN: Message with key:INVALID_SYNTAX_CANNOT_PARSE and
locale: en_US not found.
[junit] WARN: Message with key:INVALID_SYNTAX_FUZZY_LIMITS and
locale: en_US
new QueryParser fails to set constant score filter rewrite for multi-term
queries
-
Key: LUCENE-1792
URL: https://issues.apache.org/jira/browse/LUCENE-1792
Project: Lucen
[
https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1792:
---
Attachment: LUCENE-1792.patch
Patch that just adds unit test showing the issue.
We
[
https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740871#action_12740871
]
Uwe Schindler commented on LUCENE-1792:
---
Should it not set to AUTO REWRITE (even the
[
https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740879#action_12740879
]
Michael McCandless commented on LUCENE-1792:
Sorry, right, I meant AUTO REWRIT
[
https://issues.apache.org/jira/browse/LUCENE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1792:
---
Summary: new QueryParser fails to set AUTO REWRITE for multi-term queries
(was: new
[
https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740896#action_12740896
]
Robert Muir commented on LUCENE-1689:
-
Michael, I do think that would be the simplest,
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740929#action_12740929
]
Mark Miller commented on LUCENE-1771:
-
The Changes for this one is kind of complicated
Mark,
On a system where the size of the index is 10 times the amount
of RAM, lets say 10GB RAM and 100GB index, is it ok for optimize
to take 30-60 minutes? Maybe the performance trade off (10-20%
less search performance) is worth it? Otherwise the optimize
literally takes down the machine.
Perha
> Perhaps the ideal search system architecture that requires
> optimizing is to dedicate a server to it, copy the index to the
> optimize server, do the optimize, copy the index off (to a
> search server) and start again for the next optimize task.
>
> I wonder how/if this would work with Hadoop/HD
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1771:
Attachment: LUCENE-1771.patch
javadoc tweak/fix
removed explain(reader,doc)
how to handle all of
[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1771:
Attachment: LUCENE-1771.patch
One last patch - fix/doc null weight.explain null searcher issue
rem
[
https://issues.apache.org/jira/browse/LUCENE-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-1689:
Attachment: LUCENE-1689.patch
patch with a different technique for CharTokenizer and friends. I li
> You don't have to copy. You can have one machine optimize your indexes
> whilst other serves user requests, then they switch roles, rinse,
> repeat. This approach also works with sharding, and more than 2-way
> mirroring.
What does the un-optimized server do after the other server is
optimized?
19 matches
Mail list logo
