Indexierung d: Inhaltseigenschaft mit Inhalt> 32 KB

Question

Ich habe einen Alfresco-Modelltyp mit einer zusätzlichen Eigenschaft des Typs d:content. Diese Eigenschaft verursacht Solr-Ausnahmen, wenn ich versuche, Inhalte zu speichern, die größer als 32 KB sind. Die aktuelle Definition dieser Eigenschaft ist

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

Wenn ich den gesamten Inhalt, größer, dass 32 KB in dieser Eigenschaft Solr diese Ausnahme auslöst, wenn es um Index versucht es:

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. 

Ändern der index Konfiguration nicht funktioniert Hilfe, der Fehler wird mit allen Varianten von index und den Unterelementen, die ich ausprobiert habe, ausgelöst.

In another question wird beantwortet:

Die maximale Größe für den einen einzigen Begriff in dem zugrunde liegenden Lucene Index ist 32776 Bytes, das ist ich hart codiert glauben.

Wie konfiguriere ich die index eine d:content Eigenschaft so, dass ich sparen und Indizieren von Inhalten kann größer als 32 KB?

Edit:

In contentModel.xml, cm:content wie folgt konfiguriert ist:

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

eine einfache text/plain Datei mit Inhalten größer als 32 KB funktioniert ohne Probleme hinzufügen.

Die gleiche index Konfiguration für meine benutzerdefinierte Eigenschaft schlägt immer noch fehl.

Update:

Unter Alfresco 4.2fCE, das Problem tut nicht auftreten. Das ist also ein Fehler in Alfresco 5.0c zusammen mit Solr 4.1.9.

Update 2:

ich filed a bug in the Alfresco JIRA habe. 1

Answer 1

Die Lösung besteht nicht darin, das vollständige Dokument/Teil im Index zu speichern. Versuchen Sie also, store = true und tokenize = both/false für große Eigenschaften mit> 32k zu vermeiden. Die Indizierung sollte funktionieren, wenn Ihre Modelldeklaration wie folgt aussieht:

Nachteil: In meinem Test musste ich den ganzen Index fallen lassen. Ich war nicht genug, um die zwischengespeicherten Modelle in solr zu löschen

Answer 2

Hypothese

Wenn Sie Inhalte, die ähnlichen sehr lange Laufzeiten (einzelne Worte mit 32k Länge) enthält, müssen Sie Ihre eigenen Lucene Analysatoren implementieren unterstützt, dass bestimmte Art von Text. Dies bedeutet, dass es sich um ein Problem handelt, das sich auf die Standard-Lucene-Implementierung bezieht, da es fest codiert ist.

Hypothese 2

Andernfalls, wenn Sie Ihre Inhalte über die Art und Weise nicht strukturiert ist, klingt es mir fremd und wahrscheinlich ein Fehler sein könnte. Wenn Sie nicht mit tokenised = true lösen, könnte in diesem Fall eine mögliche Problemumgehung auf der Änderung des Inhaltsmodells basieren, um eine Zuordnung zwischen dem übergeordneten Knoten und dem bestimmten Knotentyp zu unterstützen, der den beteiligten Text enthält, aber den Standard cm verwendet: Inhaltseigenschaft.Ich meine mit Assoziationen, die Sie lösen sollten;)

Hoffe, das hilft.