it was repoened has been resolved. Any new issues should get their own
JIRA issue
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New
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
of this JIRA isse:
http://www.nabble.com/Re%3A--jira--Commented%3A-Search-Components-%28plugins%29-to15227648.html#a15227648
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project
is preferred over
an interface for things that a user will extend... that way signature changes
can be made in a backward compatible manner.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
, 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
...
the committed version of this patch is not commented out:
http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/core/SolrCore.java
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira
, searchComponents );
NamedListPluginLoaderSearchComponent loader = new
NamedListPluginLoaderSearchComponent( xpath, components );
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project
' components, use:
arr name=first-components
strfirst/str
/arr
arr name=last-components
strlast/str
/arr
--
/requestHandler
{code}
Search Components (plugins)
---
Key: SOLR-281
URL: https
,
and so a user could add their component at any point. Perhaps your first/last
is sufficient though.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
facet and mlt without specifying the
whole chain.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Components: search
not require everyone to update their solrconfig.xml
When SOLR-414 is committed, I will attach a patch using this strategy.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
if not; +1
otherwise.
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
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541786
]
Yonik Seeley commented on SOLR-281:
---
I'm checking out the latest version now...
Search Components (plugins
PROTECTED]):
I'm checking out the latest version now...
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Reporter
Version/s: 1.3
The core changes are committed in rev594268.
I will resolve this issue and open a new issue to track cleaning up the
ResponseBuilder
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-281.
Resolution: Fixed
Lets track ResponseBuilder issues with SOLR-410
Search Components (plugins
the ResponseBuilder
public variables to private vars with get/set methods.
How do you feel about committing this and working out the ResponseBuilder
details in subsequent smaller patches?
Search Components (plugins)
---
Key: SOLR-281
strorg.apache.solr.handler.component.DebugComponent/str
/arr
/requestHandler
Perhaps the components should be passed the init params?
Unless there is a compelling reason, I don't think components need to be shared
across request handlers thus justifying a top level component registry.
Search Components
}
That's OK, the one you produced fails for me on a clean checkout too looks
like maybe we hit a little corner case with patch/diff.
Should we perhaps commit this working version, marking ResponseBuilder as
in-flux, and then continue generating patches from that???
Search Components (plugins
...
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
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
deleting.
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
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
version, marking ResponseBuilder as
in-flux, and then continue generating patches from that???
If you feel comfortable with the big picture, yes, I think we should commit
this and refine the ResponseBuilder and perhaps the configuration options in
smaller patches.
Search Components
() 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
we
got Yonik's proper version.
junit 0 errors 0 failures.
Same patch production process.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type
Ryan's patch versions, I attached the patch as solr-281.patch (*not* as
SOLR-281-SearchComponents.patch)
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
(pluggable query parser stuff... SOLR-334)
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
was also going to suggest that it might be a good
idea to support class shorthand notation, so
org.apache.solr.handler.component.* can be written solr.component.* in
solrconfig.xml.
Search Components (plugins)
---
Key: SOLR-281
URL
org.apache.solr.handler.component. to the base list, you could just
configure: org.apache.solr.handler.component.QueryComponent
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
time to check this out, that would be great.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Reporter: Ryan
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
, would it be possible for you to create a new patch?
thanks,
Piete
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Built and tested successfully with junit.
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
)
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
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharad Agarwal updated SOLR-281:
Comment: was deleted
Search Components (plugins)
---
Key
looking at it.
Of course!
Search Components (plugins)
---
Key: SOLR-281
URL: https://issues.apache.org/jira/browse/SOLR-281
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Sharad,
I'm interested in implementing MoreLikeThis support in the Dismax request
handler (see SOLR-295) and it seems the best way forward is through the
search components idea suggested in SOLR-281. I'm not actively working on
it at the moment either but I think it's an important development
to Solr development so I'm afraid my
contributions to this issue would be mostly limited to (hopefully helpful)
ideas and suggestions however I'm happy to tinker with the patched code from
above and help test this new component framework as it is developed.
cheers,
Pieter
Search Components
- implementation that mimics
the current Standard query.
It is mostly intended to flush out design issues.
This works by sticking a 'ResponseBuilder' in the context and sharing that
between each component.
Search Components (plugins)
---
Key: SOLR-281
assuming those stages exist. (which again is how many of the other
engines do things)
- will
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik
Seeley
Sent: Sunday, June 10, 2007 12:51 PM
To: solr-dev@lucene.apache.org
Subject: search components
: // choose one query method
: docs = Query( req, debug )
:- standard
:- dismax
:- mlt (as input)
there are two small hitches to an approach like this, the first is that
you'd like to reuse more of hte query processing then to just say go pick
the list of docs basedo nthe reuqest
: for (component : ListComponent) {
: // a chance to communicate needs to other components?
: // highlighting needs a Query or terms, and a list of fields
: // faceting needs a base DocSet
: component.prepare(req, rsp);
: }
:
: while (not all components done) {
: for (component :
the second hitch is that docs only makes sense in ssuedo code ... in
reality there are DocSets and DocLists, and the efficiencies of geting
only one instead of both can be significant, but if the first phase of
processing doesn't know what expectations the later phases have (facet or
not?
stage hands on access to the searcher... crap looks
like ryan beat me by 3 minutes. oh well, what he said.
- will
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 2:27 PM
To: solr-dev@lucene.apache.org
Subject: Re: search components
:
: One interesting/difficult part would be the standardization of the
: communication between components.
Communication can be coordinated with things like
SolrQueryRequest.getContext() ... it will have to be fairly loose
communication governed by convetion, but i don't see anyway to avoid
On 6/11/07, Ryan McKinley [EMAIL PROTECTED] wrote:
while (not all components done) {
for (component : ListComponent) {
boolean done = component.process(req,rsp);
}
}
- - - - -
Yonik, what components do you imagine need to run multiple times?
Not sure... a component that needs to run
On 6/11/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 6/11/07, Ryan McKinley [EMAIL PROTECTED] wrote:
while (not all components done) {
for (component : ListComponent) {
boolean done = component.process(req,rsp);
}
}
- - - - -
Yonik, what components do you imagine need to run
Some people have needed some custom query logic, and they had to
implement their own request handlers. They still wanted all of the
other functionality (or almost all), so they are forced to copy the
standard request handler or dismax, or both. That's not the easiest to
maintain, and could be
Looking toward the future, and distributed search, this might be a
natural place to add hooks to implement that distributed logic. This
would allow other people to efficiently support their custom
functionality in a distributed environment.
Thoughts?
I like it. As is the prospect of adding
On 6/10/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Looking toward the future, and distributed search, this might be a
natural place to add hooks to implement that distributed logic. This
would allow other people to efficiently support their custom
functionality in a distributed
I very much support a plugin architecture for ResponseHandlers.
One aspect could be a Responselet which adds something to the response, as
detailed in Ryan's example below. Quite valuable in itself.
But another aspect could be a Querylet which adds something to the query
before execution.
52 matches
Mail list logo
