[
http://issues.apache.org/jira/browse/LUCENE-365?page=comments#action_12373488 ]
paul.elschot commented on LUCENE-365:
-
For the normal case with only one required subscorer this patch is ok., but for
the case with
more required subscorers, a better imp
[
http://issues.apache.org/jira/browse/LUCENE-365?page=comments#action_12373489 ]
paul.elschot commented on LUCENE-365:
-
For top level disjunctions, the original BooleanScorer could well be the best
performing one.
To have this it would be necessary to
Having switched the highlighter over from lots of
Query-specific code to using the generic
Query.extractTerms API I realize I have both gained
something (support for all query types) and lost
something (detailed boost info for each term in the
tree eg Fuzzy spelling variants). The boost info was
us
On Apr 6, 2006, at 2:52 AM, mark harwood wrote:
Maybe we should have as a standard part of Query:
//immediate child queries only
Query [] getNestedQueries();
and...
//immediate terms only
Term [] getTerms();
FWIW: In KinoSearch, I have extract_terms set up to return either a
Term
[
http://issues.apache.org/jira/browse/LUCENE-540?page=comments#action_12373500 ]
Dan Armbrust commented on LUCENE-540:
-
Fix verified here.
Thanks for the rapid repair.
> Merging multiple indexes does not maintain document order.
> ---
On 4/6/06, mark harwood <[EMAIL PROTECTED]> wrote:
> Maybe we should have as a standard part of Query:
>
> //immediate child queries only
> Query [] getNestedQueries();
It's still the case that you often need to know what type of query the
parent is.
For example, a BooleanQuery with mandatory,
[ http://issues.apache.org/jira/browse/LUCENE-514?page=all ]
Yonik Seeley closed LUCENE-514:
---
Resolution: Fixed
Assign To: Yonik Seeley
Thanks Eric, I renamed the method to be more descriptive (since we aren't using
Java5),
threw in an implement
On Thursday 06 April 2006 18:53, Yonik Seeley wrote:
> On 4/6/06, mark harwood <[EMAIL PROTECTED]> wrote:
> > Maybe we should have as a standard part of Query:
> >
> > //immediate child queries only
> > Query [] getNestedQueries();
This is another way to deal with composed queries:
http://svn.
[ http://issues.apache.org/jira/browse/LUCENE-512?page=all ]
Yonik Seeley closed LUCENE-512:
---
Resolution: Fixed
Committed.
Thanks Frederic!
> ClassCastException in ParallelReader class
> --
>
> Key: LU
[ http://issues.apache.org/jira/browse/LUCENE-500?page=all ]
Yonik Seeley closed LUCENE-500:
---
Fix Version: 2.0
Resolution: Fixed
Assign To: Yonik Seeley
Closing... I think we pretty much covered this.
> Lucene 2.0 requirements - Remove all
> It's still the case that you often need to know what
> type of query the
> parent is.
For highlighting purposes I typically don't need/want
to concern myself too much with precisely interpreting
the specifics of all Query logic:
* For Boolean queries the "mustNot" terms typically
don't appear in
On Apr 4, 2006, at 10:23 AM, Tatu Saloranta wrote:
So in this case, what would give more comparable results (assuming
you are interested in measuring likely server-side
usage scenario, which is usually what Lucene is used for)
My main interest with these tests is algorithmic performance. How
QueryParser doesn't support keywords staring with *
---
Key: LUCENE-542
URL: http://issues.apache.org/jira/browse/LUCENE-542
Project: Lucene - Java
Type: Bug
Components: QueryParser
Versions: 1.9
Environme
13 matches
Mail list logo
