Indicizzazione d: proprietà del contenuto con contenuto> 32 KB

Question

Ho un modello di tipo Alfresco con una proprietà aggiuntiva di tipo d:content. Questa proprietà causa eccezioni Solr quando provo a memorizzare contenuti di dimensioni superiori a 32 KB. L'attuale definizione di questa proprietà è

<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> 

Se metto contenuti più grande che 32 KB in questa proprietà, Solr genera questa eccezione quando cerca di indicizzarlo:

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. 

Modifica della configurazione index non aiuto, l'errore viene generato con tutte le varianti di index e gli elementi secondari che ho provato.

In another question si risponde:

La dimensione massima per il singolo un termine nell'indice Lucene sottostante è 32776 byte, che è credo disco codificato.

Come si configura il index di una proprietà d:content modo che io possa salvare e indicizzare i contenuti superiori a 32 KB?

Edit:

In contentModel.xml, cm:content è configurato in questo modo:

<index enabled="true"> 
    <atomic>true</atomic> 
    <stored>false</stored> 
    <tokenised>true</tokenised> 
</index> 

L'aggiunta di un semplice file text/plain con un contenuto maggiore di 32 KB funziona senza problemi.

La stessa configurazione index per la mia proprietà personalizzata non riesce ancora.

Aggiornamento:

Sotto Alfresco 4.2fCE, il problema non non si verificano. Quindi questo è un bug in Alfresco 5.0c insieme a Solr 4.1.9.

Aggiornamento 2:

ho filed a bug in the Alfresco JIRA.

Answer 1

La soluzione non è memorizzare l'intero documento/parte nell'indice. Quindi cerca di evitare store = true e tokenize = both/false su grandi proprietà aventi> 32k. L'indicizzazione dovrebbe funzionare se la dichiarazione del modello è la seguente:

<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> 

svantaggio: nel mio test ho dovuto rilasciare l'intero indice. Non ero in grado di eliminare i modelli memorizzati nella cache in solr

Answer 2

Ipotesi 1

Se si dispone di contenuti che contengono simili molto lunghe termini (parole singole con 32k di lunghezza), è necessario implementare i propri analizzatori di Lucene per il supporto di quel tipo specifico di testo. Ciò significa che si tratta di un problema relativo all'implementazione Lucene predefinita perché è hardcoded.

Ipotesi 2

caso contrario, se il contenuto non è strutturato nel modo sopra, suona strano per me e, probabilmente, potrebbe essere un bug. Se non stai risolvendo usando tokenised = true, in questo caso, una potenziale soluzione potrebbe essere basata sulla modifica del modello di contenuto per supportare un'associazione tra il nodo padre e il tipo specifico di nodo che contiene il testo coinvolto ma utilizzando il cm predefinito: proprietà del contenuto.Intendo usare le associazioni che dovresti risolvere;)

Spero che questo aiuti.