Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Lucene: Java-Dev

[jira] Issue Comment Edited: (LUCENE-2064) Highlighter should support all MultiTermQuery subclasses without casts

 

 

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded


jira at apache

Nov 13, 2009, 4:13 PM

Post #1 of 2 (193 views)
Permalink
[jira] Issue Comment Edited: (LUCENE-2064) Highlighter should support all MultiTermQuery subclasses without casts

[ https://issues.apache.org/jira/browse/LUCENE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777756#action_12777756 ]

Uwe Schindler edited comment on LUCENE-2064 at 11/14/09 12:12 AM:
------------------------------------------------------------------

One comment to the patch:
If a MTQ subclass does something special during rewrite or in its FilteredTermEnum and calls any other method of FakeReader, it throws NPE. You should catch this Exception and in this case fall back to extract no terms.

*EDIT*

Or simply use the passed in reader as delegate of FakeReader, then it will behave correctly for all methods.

was (Author: thetaphi):
One comment to the patch:
If a MTQ subclass does something special during rewrite or in its FilteredTermEnum and calls any other method of FakeReader, it throws NPE. You should catch this Exception and in this case fall back to extract no terms.

> Highlighter should support all MultiTermQuery subclasses without casts
> ----------------------------------------------------------------------
>
> Key: LUCENE-2064
> URL: https://issues.apache.org/jira/browse/LUCENE-2064
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/highlighter
> Affects Versions: 2.9.1
> Reporter: Simon Willnauer
> Assignee: Simon Willnauer
> Fix For: 3.0
>
> Attachments: LUCENE-2064.txt
>
>
> In order to support MultiTermQuery subclasses the Highlighter component applies instanceof checks for concrete classes from the lucene core. This prevents classes like RegexQuery in contrib from being supported. Introducing dependencies on other contribs is not feasible just for being supported by the highlighter.
> While the instanceof checks and subsequent casts might hopefully go somehow away in the future but for supporting more multterm queries I have a alternative approach using a fake IndexReader that uses a RewriteMethod to force the MTQ to pass the field name to the given reader without doing any real work. It is easier to explain once you see the patch - I will upload shortly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene


jira at apache

Nov 13, 2009, 5:05 PM

Post #2 of 2 (176 views)
Permalink
[jira] Issue Comment Edited: (LUCENE-2064) Highlighter should support all MultiTermQuery subclasses without casts [In reply to]

[ https://issues.apache.org/jira/browse/LUCENE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777781#action_12777781 ]

Mark Miller edited comment on LUCENE-2064 at 11/14/09 1:05 AM:
---------------------------------------------------------------

bq. Introducing dependencies on other contribs is not feasible just for being supported by the highlighter.

Oh its feasible :) We already depend on the only contrib that currently has a multiterm query - regex - and memory index. But it looks like the regex dependency snuck in there while working on the spanregexquery support - I don't think its actually needed anymore - we should remove it. Its only a build dependency, so its not actually a big deal - just annoying if it happened to keep growing.

*edit*

Hmm - actually, it looks like we can't avoid those dependencies after all - not if we want to test those queries - looks like the contrib dependency on regex stays anyway. Forgot its just there for the tests now.

was (Author: markrmiller [at] gmail):
bq. Introducing dependencies on other contribs is not feasible just for being supported by the highlighter.

Oh its feasible :) We already depend on the only contrib that currently has a multiterm query - regex - and memory index. But it looks like the regex dependency snuck in there while working on the spanregexquery support - I don't think its actually needed anymore - we should remove it. Its only a build dependency, so its not actually a big deal - just annoying if it happened to keep growing.

> Highlighter should support all MultiTermQuery subclasses without casts
> ----------------------------------------------------------------------
>
> Key: LUCENE-2064
> URL: https://issues.apache.org/jira/browse/LUCENE-2064
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/highlighter
> Affects Versions: 2.9.1
> Reporter: Simon Willnauer
> Assignee: Simon Willnauer
> Fix For: 3.0
>
> Attachments: LUCENE-2064.patch, LUCENE-2064.txt
>
>
> In order to support MultiTermQuery subclasses the Highlighter component applies instanceof checks for concrete classes from the lucene core. This prevents classes like RegexQuery in contrib from being supported. Introducing dependencies on other contribs is not feasible just for being supported by the highlighter.
> While the instanceof checks and subsequent casts might hopefully go somehow away in the future but for supporting more multterm queries I have a alternative approach using a fake IndexReader that uses a RewriteMethod to force the MTQ to pass the field name to the given reader without doing any real work. It is easier to explain once you see the patch - I will upload shortly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.