[
https://issues.apache.org/jira/browse/SOLR-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128682#comment-13128682
]
Chris Male edited comment on SOLR-2842 at 10/17/11 5:52 AM:
------------------------------------------------------------
I really agree with Yonik here. I'm very wary of making the client API any
more complex. There are many processing pipeline implementations out there,
why should ours go client-side? It'd only benefit those using SolrJ and come at
the cost of increased complexity. Having to check that the UpdateProcessor is
running on on a client or server and then throwing Exceptions in certain
circumstances... it all just feels a little messy!
The Tika processing situation seems a different problem which Yonik's
suggestion seems very reasonable - have a local Solr instance that replicates.
I also agree with Mark. We shouldn't strip access to SolrCore, but I think we
can reach a middle ground where the UpdateProcessor can define whether it wants
a SolrCore reference? Bean setters anybody? The same goes for any Schemas /
ResourceLoaders. We should make them all optional but definitely accessible.
I don't want to seem like a downer, because I am fully for any refactorings and
cleanups of these interfaces where possible.
was (Author: cmale):
I really agree with both Yonik's here. I'm very wary of making the client
API any more complex. There are many processing pipeline implementations out
there, why should ours go client-side? It'd only benefit those using SolrJ and
come at the cost of increased complexity. Having to check that the
UpdateProcessor is running on on a client or server and then throwing
Exceptions in certain circumstances... it all just feels a little messy!
The Tika processing situation seems a different problem which Yonik's
suggestion seems very reasonable - have a local Solr instance that replicates.
I also agree with Mark. We shouldn't strip access to SolrCore, but I think we
can reach a middle ground where the UpdateProcessor can define whether it wants
a SolrCore reference? Bean setters anybody? The same goes for any Schemas /
ResourceLoaders. We should make them all optional but definitely accessible.
I don't want to seem like a downer, because I am fully for any refactorings and
cleanups of these interfaces where possible.
> Re-factor UpdateChain and UpdateProcessor interfaces
> ----------------------------------------------------
>
> Key: SOLR-2842
> URL: https://issues.apache.org/jira/browse/SOLR-2842
> Project: Solr
> Issue Type: Improvement
> Components: update
> Reporter: Jan Høydahl
>
> The UpdateChain's main task is to send SolrInputDocuments through a chain of
> UpdateRequestProcessors in order to transform them in some way and then
> (typically) indexing them.
> This generic "pipeline" concept would also be useful on the client side
> (SolrJ), so that we could choose to do parts or all of the processing on the
> client. The most prominent use case is extracting text (Tika) from large
> binary documents, residing on local storage on the client(s). Streaming
> hundreds of Mb over to Solr for processing is not efficcient. See SOLR-1526.
> We're already implementing Tika as an UpdateProcessor in SOLR-1763, and what
> would be more natural than reusing this - and any other processor - on the
> client side?
> However, for this to be possible, some interfaces need to change slightly..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
