Hi Erik,
thanks for your concerns and thoughts.
There is no XY problem because we decouple input (storing)
from, searching, faceting, ...
What you see is just the input for storing and output of the original
text in the results. There is no need to do any analysis on this.
So don't worry, it works
I've got to ask _how_ are you intending to search this field? On the
surface, this feels like an XY problem.
It's a "string" type. Therefore, if this is the input:
102, 111, 114, 32, 97, 32, 114, 101, 118, 105, 101, 119, 32, 115, 101,
101, 32, 66, 114
you'll only ever get a match if you search ex
It turned out that I didn't recognized that dcdescription is not indexed,
only stored. So the next in "chain" ist f_dcperson where dccreator and
dcdescription is combined and indexed. And this is why the error
shows up on f_dcperson. ("delay of error")
Thanks for your help, regards.
Bernd
Am 11.
On 5/11/2015 7:19 AM, Bernd Fehling wrote:
> After reading https://issues.apache.org/jira/browse/LUCENE-5472
> one question still remains.
>
> Why is it complaining about f_dcperson which is a copyField when the
> origin problem field is dcdescription which definately is much larger
> than 32766?
>
Hi Emir,
ahhh, yes you're right. I missed that. Now I understand why it is not
complaining about dcdescription and the error shows up on f_dcperson.
"delay of error" ;-)
Thanks
Bernd
Am 11.05.2015 um 15:25 schrieb Emir Arnautovic:
> Hi Bernrd,
> dcdescription field is not indexed.
>
> Thanks,
Hi Shawn,
that means if I set a length limit on dcdescription or make dcdescription
multivalue
than the problem is solved because f_dcperson is already multivalue?
Regards
Bernd
Am 11.05.2015 um 15:17 schrieb Shawn Heisey:
> On 5/11/2015 6:13 AM, Bernd Fehling wrote:
>> Caused by: java.lang.Il
Hi Bernrd,
dcdescription field is not indexed.
Thanks,
Emir
--
Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support * http://sematext.com/
On 11.05.2015 15:22, Bernd Fehling wrote:
Hi Emir,
the dcdescription field is definately to big.
But why i
After reading https://issues.apache.org/jira/browse/LUCENE-5472
one question still remains.
Why is it complaining about f_dcperson which is a copyField when the
origin problem field is dcdescription which definately is much larger
than 32766?
I would assume it complains about dcdescription field.
Hi Emir,
the dcdescription field is definately to big.
But why is it complaining about f_dcperson and not dcdescription?
Regards
Bernd
Am 11.05.2015 um 15:12 schrieb Emir Arnautovic:
> Hi Bernd,
> Issue is with f_dcperson and what ends up in that field. It is configured to
> be string, which m
On 5/11/2015 6:13 AM, Bernd Fehling wrote:
> Caused by: java.lang.IllegalArgumentException: Document contains at least one
> immense term
> in field="f_dcperson" (whose UTF8 encoding is longer than the max length
> 32766), all of which were skipped.
> Please correct the analyzer to not produce su
Hi Bernd,
Issue is with f_dcperson and what ends up in that field. It is
configured to be string, which means it is not tokenized so if some huge
value is in either dccreator or dccontributor it will end up as single
term. Nemes suggest that it should not contain such values, but double
check
I'm getting the following error with 4.10.4
WARN org.apache.solr.handler.dataimport.SolrWriter – Error creating document :
SolrInputDocument(fields: [dcautoclasscode=310, dclang=unknown,
..., dcdocid=dd05ad427a58b49150a4ca36148187028562257a77643062382a1366250112ac])
org.apache.solr.comm
12 matches
Mail list logo
