Entfernen des generischen Lucene-Index generic-lucene-index-removal
Adobe beabsichtigt, den generischen Lucene-Index (/oak:index/lucene-*
) aus Adobe Experience Manager as a Cloud Service zu entfernen. Dieser Index wird seit AEM 6.5 nicht mehr unterstützt. In diesem Dokument werden die Auswirkungen dieser Entscheidung beschrieben. Außerdem finden Sie detaillierte Beschreibungen, wie Sie untersuchen können, ob eine AEM-Instanz betroffen ist. Es enthält auch Möglichkeiten, Abfragen so zu ändern, dass sie weiterhin ohne den generischen Lucene-Index funktionieren.
Hintergrund background
In AEM sind Volltextabfragen diejenigen, die die folgenden Funktionen verwenden:
jcr:contains()
in JCR XPATHCONTAINS
in JCR-SQL2
Solche Abfragen können keine Ergebnisse ohne Verwendung eines Index zurückgeben. Im Gegensatz zu Abfragen, die nur Pfad- oder Eigenschaftsbeschränkungen enthalten, liefert eine Abfrage mit einer Volltextbeschränkung, für die kein Index gefunden werden kann (und daher eine Umkehrung durchgeführt wird), immer null Ergebnisse.
Den generischen Lucene-Index (/oak:index/lucene-*
) gibt es seit AEM 6.0/Oak 1.0, um eine Volltextsuche über den Großteil der Repository-Hierarchie hinweg zu ermöglichen, obwohl einige Pfade, wie z. B. /jcr:system
und /var
immer ausgeschlossen wurden. Dieser Index wurde jedoch weitgehend durch Indizes für spezifischere Knotentypen ersetzt (z. B. damAssetLucene-*
für den Knotentyp dam:Asset
), die sowohl Volltext- als auch Eigenschaftensuchen unterstützen.
In AEM 6.5 wurde der generische Lucene-Index als veraltet markiert, was darauf hinweist, dass er in zukünftigen Versionen entfernt wird. Seither wurde eine WARNUNG protokolliert, wenn der Index verwendet wurde, wie durch das folgende Protokoll-Snippet veranschaulicht:
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex This index is deprecated: /oak:index/lucene-2; it is used for query Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where contains(*, 'search term') and isdescendantnode(a, '/content/mysite') /* xpath: /jcr:root/content/mysite//*[jcr:contains(.,"search term")] */ fullText="search" "term", path=/content/mysite//*). Change the query or the index definitions.
In den letzten AEM-Versionen wurde der generische Lucene-Index verwendet, um eine sehr geringe Anzahl von Funktionen zu unterstützen. Diese werden überarbeitet, sodass sie nun andere Indizes verwenden, oder anderweitig geändert, um die Abhängigkeit von diesem Index zu entfernen.
Beispielsweise sollten Referenz-Lookup-Abfragen, wie im folgenden Beispiel, nun den Index bei /oak:index/pathreference
verwenden, der nur String
-Eigenschaftswerte indiziert, die einem regulären Ausdruck entsprechen, der nach JCR-Pfaden sucht.
//*[jcr:contains(., '"/content/dam/mysite"')]
Um größere Kundendatenvolumen zu unterstützen, erstellt Adobe für neue AEM as a Cloud Service-Umgebungen den generischen Lucene-Index nicht mehr. Darüber hinaus entfernt Adobe den Index aus vorhandenen Repositorys. Weitere Einzelheiten finden Sie in der Timeline am Ende dieses Dokuments.
Adobe hat die Indexkosten bereits über die costPerEntry
- und costPerExecution
-Eigenschaften angepasst, um sicherzustellen, dass andere Indizes wie /oak:index/pathreference
nach Möglichkeit bevorzugt werden.
Kundenanwendungen, die Abfragen verwenden, die noch von diesem Index abhängig sind, sollten unverzüglich so aktualisiert werden, dass sie andere vorhandene Indizes nutzen, die ggf. angepasst werden können. Alternativ können der Kundenanwendung neue benutzerdefinierte Indizes hinzugefügt werden. Eine vollständige Anleitung zur Indexverwaltung in AEM as a Cloud Service finden Sie in der Dokumentation zur Indizierung.
Sind Sie betroffen? are-you-affected
Der generische Lucene-Index wird derzeit als Fallback verwendet, wenn kein anderer Volltext-Index eine Abfrage bedienen kann. Wenn dieser veraltete Index verwendet wird, wird eine Meldung ähnlich der folgenden auf WARN-Ebene protokolliert:
org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex This index is deprecated: /oak:index/lucene-2; it is used for query Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where contains(*, 'test') /* xpath: //*[jcr:contains(.,"test")] */ fullText="test", path=*). Change the query or the index definitions.
Unter bestimmten Umständen versucht Oak möglicherweise, einen anderen Volltextindex zu verwenden (z. B. /oak:index/pathreference
), um die Volltextabfrage zu unterstützen. Wenn die Abfragezeichenfolge jedoch nicht mit dem regulären Ausdruck in der Indexdefinition übereinstimmt, wird eine Meldung auf WARN-Ebene protokolliert und die Abfrage liefert wahrscheinlich keine Ergebnisse.
org.apache.jackrabbit.oak.query.QueryImpl Potentially improper use of index /oak:index/pathReference with queryFilterRegex (["']|^)/ to search for value "test"
Nachdem der generische Lucene-Index entfernt wurde, wird eine Meldung wie die folgende auf WARN-Ebene protokolliert, wenn eine Volltextabfrage keine geeignete Indexdefinition finden kann:
org.apache.jackrabbit.oak.query.QueryImpl Fulltext query without index for filter Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where contains(*, 'test') /* xpath: //*[jcr:contains(.,"test")] */ fullText="test", path=*); no results are returned
Potenzielle Abhängigkeiten von generischen Lucene-Indizes potential-dependencies
Es gibt verschiedene Bereiche, in denen Ihre Anwendungen und AEM-Installationen sowohl für Autoren- als auch Veröffentlichungsinstanzen von generischen Lucene-Indizes abhängig sein können.
Veröffentlichungsinstanz publish-instance
Benutzerdefinierte Programmabfragen custom-application-queries
Die häufigste Quelle von Abfragen, die den generischen Lucene-Index auf einer Publishing-Instanz verwenden, sind benutzerdefinierte Programmabfragen.
In den einfachsten Fällen kann es sich um Abfragen ohne angegebenen Knotentyp handeln, was bedeutet, dass nt:base
oder nt:base
explizit angegeben werden, z.B.:
/jcr:root/content/mysite//*[jcr:contains(., 'search term')]
/jcr:root/content/mysite//element(*, nt:base)[jcr:contains(., 'search term')]
Beispielsweise können die Abfragen so geändert werden, dass Ergebnisse zurückgegeben werden, die mit Seiten oder einem der Aggregate unter dem cq:Page node
übereinstimmen. Die Abfrage könnte somit wie folgt lauten:
/jcr:root/content/mysite//element(*, cq:Page)[jcr:contains(., 'search term')]
In anderen Fällen kann eine Abfrage einen Knotentyp angeben, aber eine Volltextbeschränkung enthalten, die nicht von einem anderen Volltextindex verarbeitet werden kann, z. B.:
/jcr:root/content/dam//element(*, dam:Asset)[jcr:contains(jcr:content/metadata/@cq:tags, 'NewsTopics:cateogries/domestic'))]
In diesem Fall weist die Abfrage den Knotentyp dam:Asset
auf, enthält jedoch eine Volltextbeschränkung für die relative jcr:content/metadata/@cq:tags
-Eigenschaft.
Diese Eigenschaft wird im damAssetLucene
-Index, dem Volltextindex, der am häufigsten für Abfragen zum Knotentyp dam:Asset
verwendet wird, nicht als „Analysiert“ gekennzeichnet. Daher kann dieser Index nicht für diese Abfrage verwendet werden.
Deshalb greift die Abfrage auf den allgemeinen Volltextindex zurück, in dem alle eingeschlossenen Eigenschaften als durch den Wildcard-Treffer bei /oak:index/lucene-2/indexRules/nt:base/properties/prop
analysiert markiert sind.
jcr:content/metadata/@cq:tags
in einer benutzerdefinierten Version des damAssetLucene
-Index als analysiert markieren, wird diese Abfrage von diesem Index verarbeitet und es wird keine WARNUNG protokolliert.Autoreninstanz author-instance
Zusätzlich zu Abfragen in Kundenanwendungs-Servlets, OSGi-Komponenten und Render-Skripten gibt es verschiedene autorenspezifische Verwendungsmöglichkeiten für den generischen Lucene-Index.
Referenzsuche reference-search
Bisher wurde der generische Lucene-Index verwendet, um die Referenzsuche oder die Suche nach Inhalten zu unterstützen, die Verweise auf einen anderen Inhaltspfad enthalten. Solche Abfragen sollten bereits so geändert worden sein, dass sie den neuen /oak:index/pathreference
-Index verwenden.
Suche für Pfadfeldwähler picker-search
AEM enthält eine benutzerdefinierte Dialogfeldkomponente mit dem Sling-Ressourcentyp granite/ui/components/coral/foundation/form/pathfield
, die einen Browser/einen Auswahlassistenten zum Auswählen eines anderen AEM-Pfads bietet. Der standardmäßige Pfadfeldwähler, der verwendet wird, wenn keine benutzerdefinierte pickerSrc
-Eigenschaft in der Inhaltsstruktur definiert ist, rendert eine Suchleiste im Popup-Dialogfeld.
Die Knotentypen, nach denen gesucht werden soll, können mit der Eigenschaft nodeTypes
angegeben werden.
Wenn derzeit keine nodeTypes
-Eigenschaft vorhanden ist, verwendet die zugrunde liegende Suchabfrage den Knotentyp nt:base
und verwendet daher wahrscheinlich den generischen Lucene-Index, wobei in der Regel WARNUNGS-Meldungen ähnlich der folgenden protokolliert werden.
20.01.2022 18:56:06.412 *WARN* [127.0.0.1 [1642704966377] POST /mnt/overlay/granite/ui/content/coral/foundation/form/pathfield/picker.result.single.html HTTP/1.1] org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex This index is deprecated: /oak:index/lucene-2; it is used for query Filter(query=select [jcr:path], [jcr:score], * from [nt:base] as a where contains(*, 'test') and isdescendantnode(a, '/content') /* xpath: /jcr:root/content//element(*, nt:base)[(jcr:contains(., 'test'))] order by @jcr:score descending */ fullText="test", path=/content//*). Change the query or the index definitions.
Vor dem Entfernen des generischen Lucene-Index wird die Komponente pathfield
aktualisiert, sodass das Suchfeld für Komponenten mithilfe der Standardauswahl ausgeblendet wird, die keine nodeTypes
-Eigenschaft bereitstellt.
nodeTypes
-Eigenschaft angegeben werden, die die Knotentypen auflistet, für die er Abfragen durchführen möchte. Diese können als kommagetrennte Liste von Knotentypen in einer String
-Eigenschaft angegeben werden. Wenn keine Suche erforderlich ist, ist keine Aktion seitens des Kunden notwendig.dam/cfm/models/editor/components/contentreference
.- Derzeit führen diese Abfragen ohne angegebene Knotentypen durch, was dazu führt, dass aufgrund der Verwendung des generischen Lucene-Index eine WARNUNG protokolliert wird.
- Instanzen dieser Komponenten werden in Kürze automatisch ohne weitere Kundenaktion standardmäßig die Knotentypen
cq:Page
unddam:Asset
verwenden. - Die
nodeTypes
-Eigenschaft kann hinzugefügt werden, um diese standardmäßigen Knotentypen zu überschreiben.
Timeline für die Entfernung des generischen Lucene-Index timeline
Adobe wird den generischen Lucene-Index in zwei Phasen entfernen.
- Phase 1 (Geplanter Beginn am 31. Januar 2022): In neuen AEM as a Cloud Service-Umgebungen wird kein
/oak:index/lucene-*
mehr erstellt. - Phase 2 (Geplanter Beginn am 31. März 2022): Der
/oak:index/lucene-*
-Index wird aus bestehenden AEM as a Cloud Service-Umgebungen entfernt.
Adobe überwacht die oben genannten Protokollmeldungen und versucht, Kunden zu kontaktieren, die weiterhin vom generischen Lucene-Index abhängig sind.
Als kurzfristige Lösung fügt Adobe bei Bedarf benutzerdefinierte Indexdefinitionen direkt zu Kundensystemen hinzu, um Funktions- oder Leistungsprobleme aufgrund der Entfernung des generischen Lucene-Index zu vermeiden.
In solchen Fällen wird Kundinnen und Kunden die aktualisierte Indexdefinition bereitgestellt und empfohlen, diese über Cloud Manager in zukünftige Versionen ihrer Anwendung aufzunehmen.