[
https://issues.apache.org/jira/browse/SOLR-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904979#action_12904979
]
Jan Høydahl commented on SOLR-1763:
-----------------------------------
Ideally the UpdateProcessor will do everything that the RequestHandler does and
more.
We might still need a RequestHandler which is capable of accepting a binary
file as input, as well as conveying certain request parameters to the
UpdateProcessor.
But that should probably be a new thinner "RawUpdateRequestHandler".
When this more generic architecture has proven itself superior, then we can
start deprecating old stuff. DIH should then also start looking to the
UpdateProcessor for its Tika needs.
> Integrate Solr Cell/Tika as an UpdateRequestProcessor
> -----------------------------------------------------
>
> Key: SOLR-1763
> URL: https://issues.apache.org/jira/browse/SOLR-1763
> Project: Solr
> Issue Type: New Feature
> Components: update
> Reporter: Jan Høydahl
>
> From Chris Hostetter's original post in solr-dev:
> As someone with very little knowledge of Solr Cell and/or Tika, I find myself
> wondering if ExtractingRequestHandler would make more sense as an
> extractingUpdateProcessor -- where it could be configured to take take either
> binary fields (or string fields containing URLs) out of the Documents, parse
> them with tika, and add the various XPath matching hunks of text back into
> the document as new fields.
> Then ExtractingRequestHandler just becomes a handler that slurps up it's
> ContentStreams and adds them as binary data fields and adds the other literal
> params as fields.
> Wouldn't that make things like SOLR-1358, and using Tika with URLs/filepaths
> in XML and CSV based updates fairly trivial?
> -Hoss
> I couldn't agree more, so I decided to add it as an issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
