[
https://issues.apache.org/jira/browse/LUCENE-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813795#comment-13813795
]
Varun Thacker commented on LUCENE-5329:
---------------------------------------
Hi Areek,
I was asking myself the same question the other day.
I felt making payloads binary values was too restrictive. Also I thought if we
don't use binary values you could have multiple payload fields.
A use case where multiple payload fields would be useful:
You have product autosuggest in an eCommerce store.
You might want back in the suggested document - link, image url, price etc. as
payloads making it easier for someone for integrate.
Is there a negative side to making any such changes?
> Make DocumentDictionary and co more lenient to dirty documents
> --------------------------------------------------------------
>
> Key: LUCENE-5329
> URL: https://issues.apache.org/jira/browse/LUCENE-5329
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Areek Zillur
> Attachments: LUCENE-5329.patch
>
>
> Currently DocumentDictionary errors out whenever any document does not have
> value for any relevant stored fields. It would be nice to make it lenient and
> instead ignore the invalid documents.
> Another "issue" with the DocumentDictionary is that it only allows string
> fields as suggestions and binary fields as payloads. When exposing these
> dictionaries to solr (via https://issues.apache.org/jira/browse/SOLR-5378),
> it is inconvenient for the user to ensure that a suggestion field is a string
> field and a payload field is a binary field. It would be nice to have the
> dictionary "just work" whenever a string/binary field is passed to
> suggestion/payload field. The patch provides one solution to this problem (by
> accepting string or binary values), though it would be great if there are any
> other solution to this, without making the DocumentDictionary "too flexible"
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
