[
https://issues.apache.org/jira/browse/SOLR-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5698:
---------------------------
Description:
As reported on the solr-user list, when a term is greater then 2^15 bytes it is
silently ignored at indexing time -- a message is logged in to infoStream if
enabled, but no error is thrown.
seems like we should change this behavior (if nothing else starting in 5.0) to
throw an exception.
was:
As reported on the user list, when a term is greater then 2^15 bytes it is
silently ignored at indexing time -- no error is given at all.
we should investigate:
* if there is a way to get the lower level lucene code to propogate up an error
we can return to the user instead of silently ignoring these terms
* if there is no way to generate a low level error:
** is there at least way to make this limit configurable so it's more obvious
to users that this limit exists?
** should we make things like StrField do explicit size checking on the terms
they produce and explicitly throw their own error?
Summary: Long terms should generate a RuntimeException, not just
infoStream (was: exceptionally long terms are silently ignored during indexing)
revising summary & description in prep for converting to LUCENE issue
> Long terms should generate a RuntimeException, not just infoStream
> ------------------------------------------------------------------
>
> Key: SOLR-5698
> URL: https://issues.apache.org/jira/browse/SOLR-5698
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
>
> As reported on the solr-user list, when a term is greater then 2^15 bytes it
> is silently ignored at indexing time -- a message is logged in to infoStream
> if enabled, but no error is thrown.
> seems like we should change this behavior (if nothing else starting in 5.0)
> to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
