[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-dev
Subject:    [jira] Commented: (SOLR-1633) Solr Cell should be smarter about
From:       "Chris Harris (JIRA)" <jira () apache ! org>
Date:       2010-03-31 0:20:27
Message-ID: 1583495391.593171269994827274.JavaMail.jira () brutus ! apache ! org
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/SOLR-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851667#action_12851667 \
] 

Chris Harris commented on SOLR-1633:
------------------------------------

bq. It seems like a possible improvement here would be for SolrCell to ignore the \
value from Tika if it already has one that was explicitly provided (as opposed to the \
current behavior of letting hte add fail because of multiple values in a single \
valued field).

I've implemented this, or at least something pretty similar, at SOLR-1856.

> Solr Cell should be smarter about literal and multiValued="false"
> -----------------------------------------------------------------
> 
> Key: SOLR-1633
> URL: https://issues.apache.org/jira/browse/SOLR-1633
> Project: Solr
> Issue Type: Improvement
> Components: contrib - Solr Cell (Tika extraction)
> Reporter: Hoss Man
> 
> As noted on solr-user, SolrCell has less then ideal behavior when "foo" is a single \
> value field, and literal.foo=bar is specified in the request, but Tika also \
> produces a value for the "foo" field from the document.  It seems like a possible \
> improvement here would be for SolrCell to ignore the value from Tika if it already \
> has one that was explicitly provided (as opposed to the current behavior of letting \
> hte add fail because of multiple values in a single valued field). It seems pretty \
> clear that in cases like this, the users intention is to have their one literal \
> field used as the value. \
> http://old.nabble.com/Re%3A-WELCOME-to-solr-user%40lucene.apache.org-to26650071.html#a26650071
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]