[jira] Commented: (SOLR-281) Search Components (plugins)

2008-01-31 Thread Michael Dodsworth (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564449#action_12564449
 ] 

Michael Dodsworth commented on SOLR-281:


This is great; decomposing the handler and allowing the components to be wired 
up in the config really helps development (and maintenance of those changes). 

For my purposes, I needed to make a change to the way the dismax query was 
being generated. Using the DisMaxQParserPlugin as a template, I created my own 
QParser and associated QParserPlugin; changed the relevant bits; added a 
 entry in solrconfig.xml; added the 'defType' parameter to the 
wanted SearchHandler configuration...and...all works well. 
  
Just a few comments: 

* I had to make the QParser parse() method public (as the new query parser may 
still need to use the existing query parsers (backup lucene parser, boost 
parser, function parser, etc). 
* The QParserPlugin class seems unnecessary: all it does is implement init() 
and add a createParser method. Why not just have the parser constructor take 
those arguments...or, if that can't be done, create an interface to allow the 
parser itself implement both init() and createParser() (or create()). It then 
avoids having to create 2 classes (in the case of DisMax, in the same 
file...which is not pretty).

> Search Components (plugins)
> ---
>
> Key: SOLR-281
> URL: https://issues.apache.org/jira/browse/SOLR-281
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-281-ComponentInit.patch, 
> SOLR-281-ComponentInit.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> solr-281.patch, solr-281.patch, solr-281.patch
>
>
> A request handler with pluggable search components for things like:
>   - standard
>   - dismax
>   - more-like-this
>   - highlighting
>   - field collapsing 
> For more discussion, see:
> http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#a11050274

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



[jira] Commented: (SOLR-281) Search Components (plugins)

2008-02-01 Thread Michael Dodsworth (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564739#action_12564739
 ] 

Michael Dodsworth commented on SOLR-281:


{quote} 
That would require instantiation with reflection I think. 
{quote} 

Reflection is already being used to create the QParserPlugins (SolrCore:1027 
and AbstractPluginLoader:83) - I'm guessing the reason for the plugin is just 
to avoid creating instances through reflection on every parse (as you could 
keep hold of the QParser class and call newInstance). The second point is moot, 
once you take away the need for createParser(...). 

It's really not that big-a-deal, in the scheme of things. 

{quote} 
QParserPlugin is that interface essentially (except that its an class instead 
of an interface). For library maintainers an abstract class is preferred over 
an interface for things that a user will extend... that way signature changes 
can be made in a backward compatible manner. 
{quote} 

As an aside, method signature changes are usually trivial to fix; personally, 
the pain of those fixes is favourable to extending an abstract class 
unnecessarily. 
Are there any architectural reworking projects on the roadmap? I'm sure 
backward compatibility is a massive concern; perhaps with the more modular 
plugin design route Solr is going down, those concerns can be addressed. If 
there's a chance of being accepted, I would love to contribute a move towards 
using Spring. 



> Search Components (plugins)
> ---
>
> Key: SOLR-281
> URL: https://issues.apache.org/jira/browse/SOLR-281
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-281-ComponentInit.patch, 
> SOLR-281-ComponentInit.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch, 
> solr-281.patch, solr-281.patch, solr-281.patch
>
>
> A request handler with pluggable search components for things like:
>   - standard
>   - dismax
>   - more-like-this
>   - highlighting
>   - field collapsing 
> For more discussion, see:
> http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#a11050274

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