[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley updated SOLR-281:
------------------------------
Attachment: solr-281.patch
Here's a new (smaller) patch that utilizes pluggable query
parsers, and
- removes DisMax specific modules since dismax specific
logic is limited to query construction
- DisMax request handler is now just the standard handler
with defType=dismax added as a default
- removed variable RequestBuilder class logic since it seems
unnecessary... if two non-standard components want to
communicate something, they can use the Context or the
Response. (any reason I'm missing why it should stay?)
Thoughts on these changes?
We need to think through all the members of ResponseBuilder
carefully and decide what component sets/reads them in what
phase (and if that makes the most sense).
Should ResponseBuilder have methods instead of members? If
so, that would allow a component to perhaps even replace the
ResponseBuilder and delegate to the original.
How will a users custom component get configuration? Should
components be a full plugins with an init() for
configuration?
> Search Components (plugins)
> ---------------------------
>
> Key: SOLR-281
> URL: https:
//issues.apache.org/jira/browse/SOLR-281
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Attachments: 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-compo
nents-%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.
|
