[
https://issues.apache.org/jira/browse/SOLR-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129448#comment-13129448
]
Chris Male commented on SOLR-2842:
----------------------------------
Ryan is on the right track here. Really many of these changes are just related
to the 'Add' update logic. UpdateProcessor provides a lot of integration with
Solr's CRUD features and I think we should leave it that way. If we want to
provide a cleaner system for doing Document manipulations that would be part of
adding a Document, then lets keep the focus on that.
Having a simple interface like Ryan suggests seems the best way to go forward.
Then all the actual meat of the Document manipulation logic can go there.
Integration with UpdateProcessor seems pretty straightforward. It then frees
us up to tackle configuration / DSLs / reuse / whatever else buzzword, without
changing the already powerful and functional UpdateProcessor framework.
> 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]
