[
https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627333#action_12627333
]
Chris Harris commented on SOLR-284:
-----------------------------------
While we're on the subject of breaking changes, I'm now seeing some merit in
replacing the fieldnames parameter with a field-specifying prefix.
Currently when you want to set a non-body field, you introduce the field name
in the fieldnames parameter and then specify its value in another parameter,
like so:
/update/rich/...fieldnames=f1,f2,f3&f1=val1&f2=val2&f3=val3
The alternative would be to to signal the fields f1, f2, and f3 by a field
prefix, like so:
/update/rich/...f.f1=val1&f.f2=val2&f.f3=val3
Because the f prefix says "this is a field", there's no need for the fieldnames
parameter.
This isn't an Earth-shattering improvement, but there are three things I like
about it:
1. The URLs are shorter
2. If you rename a field (e.g. rename f3 to g3), you can't accidentally
half-update the URL in the client code, like this:
/update/rich/...fieldnames=f1,f2,g3&f1=val1&f2=val2&f3=val3
3. Currently there are certain reserved words (e.g. "fieldnames", "commit")
that you can't use, because they have special meaning to the handler. But with
this change they become legitimate field names. For example, maybe I want each
of my documents to have a "commit" field that describes who made the most
recent relevant commit in a version control system.
/update/rich/...commit=true&f.commit=chris
I can't think of any downsides right now, other than breaking people's code. (I
do admit that is a downside.)
Any comments?
> Parsing Rich Document Types
> ---------------------------
>
> Key: SOLR-284
> URL: https://issues.apache.org/jira/browse/SOLR-284
> Project: Solr
> Issue Type: New Feature
> Components: update
> Reporter: Eric Pugh
> Fix For: 1.4
>
> Attachments: libs.zip, rich.patch, rich.patch, rich.patch,
> rich.patch, rich.patch, source.zip, test-files.zip, test-files.zip, test.zip,
> un-hardcode-id.diff
>
>
> I have developed a RichDocumentRequestHandler based on the CSVRequestHandler
> that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into
> Solr.
> There is a wiki page with information here:
> http://wiki.apache.org/solr/UpdateRichDocuments
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
