solr - Indexación d: propiedad de contenido con contenido> 32 KB
alfresco (2)
Tengo un tipo de modelo Alfresco con una propiedad adicional de tipo d:content . Esta propiedad causa excepciones de Solr cuando intento almacenar contenido de más de 32 KB en él. La definición actual de esta propiedad es
<property name="acme:secondContent">
<type>d:content</type>
<mandatory>false</mandatory>
<index enabled="true">
<atomic>true</atomic>
<stored>true</stored>
<tokenised>both</tokenised>
</index>
</property>
Si pongo contenido de más de 32 KB en esta propiedad, Solr arroja esta excepción cuando intenta indexarlo:
java.lang.IllegalArgumentException: Document contains at least one immense term in field="content@s____@{http://acme.com/model/custom/1.0}secondContent" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms.
Cambiar la configuración del index no ayuda, el error se produce con todas las variantes del index y los subelementos que he probado.
En otra pregunta , se responde:
El tamaño máximo para un solo término en el índice Lucene subyacente es 32776 bytes, que creo que está codificado.
¿Cómo configuro el index de una propiedad d:content para poder guardar e indexar contenido de más de 32 KB?
Editar:
En contentModel.xml , cm:content está configurado así:
<index enabled="true">
<atomic>true</atomic>
<stored>false</stored>
<tokenised>true</tokenised>
</index>
Agregar un archivo de text/plain simple text/plain con contenido de más de 32 KB funciona sin problemas.
La misma configuración de index para mi propiedad personalizada aún falla.
Actualizar:
En Alfresco 4.2fCE, el problema no ocurre. Así que este es un error en Alfresco 5.0c junto con Solr 4.1.9.
Actualización 2:
Hipótesis 1
Si tiene contenidos que contienen términos similares muy largos (palabras sueltas con 32k de longitud), debe implementar sus propios analizadores Lucene para admitir ese tipo específico de texto. Esto significa que es un problema relacionado con la implementación predeterminada de Lucene porque está codificado.
Hipótesis 2
De lo contrario, si su contenido no está estructurado de la manera anterior, me parece extraño y probablemente podría ser un error. Si no está resolviendo con tokenised = true, en este caso, una posible solución podría basarse en cambiar el modelo de contenido para admitir una asociación entre el nodo primario y el tipo específico de nodo que contiene el texto involucrado pero utilizando el cm predeterminado: propiedad de contenido. Me refiero al uso de asociaciones que debes resolver;)
Espero que esto ayude.
La solución no es almacenar el doc / part completo en el índice. Intente evitar store = true y tokenize = both / false en propiedades grandes que tengan> 32k. La indexación debería funcionar si su declaración de modelo se ve así:
<property name="acme:secondContent">
<type>d:content</type>
<mandatory>false</mandatory>
<index enabled="true">
<atomic>true</atomic>
<stored>false</stored>
<tokenised>true</tokenised>
</index>
</property>
inconveniente: en mi prueba tuve que soltar todo el índice. No fui suficiente para eliminar los modelos en caché en solr