Questions & Answers

[arnbae]

Hallo,

ich habe folgendes Problem und die Frage, ob hier irgend jemand schon Erfahrungen oder eine Abhilfe weiß.

Einen in FS 3.1 mit FS-SEARCH erzeugten Lucene-Index konnte ich bisher ohne weiteres mit dem PHP-Framework (>1.6.0) von ZEND weiterverarbeiten: Suche, Zugriff auf Dokumentenfelder etc. ging. Ich musste lediglich den segmentierten Index, den FS erzeugte, mit $index->optmize() noch etwas performanter gestalten.

Mit dem unter FS 4.2 erzeugten Index kommt das Framework aber nicht mehr klar: Obwohl ich mit LUKE den Index und alle Felder lesen kann, bekomme ich die wildesten Fehler und Probleme:

• Zugriff auf Dokumente: Da versucht PHP mehrere hundert MB Speicher zu allozieren (bei einem Index von 100 KB Größe)
• Einzelne Felder werden zwar in den Feldlisten des Index aufgeführt (getFieldNames), sind aber in den Dokumenten nicht vorhanden
• Die Ausgabe von Feldern wie "Content" ergibt häufig Müll.

Hat jemand ein ähnliches Problem und vielleicht die Lösung dazu? Und nein, ich kann nicht den Java-Adapter verwenden. Leider nicht.

Grüße,

Arndt Bär

[feddersen]

Unter 4.2 wird Lucene 2.3.2 verwendet, laut der Dokumentation kann die Komponente des Zend Frameworks wohl nur Lucene 2.1.

[arnbae]

Hallo & Danke für die schnelle Antwort,

war auch meine erste Vermutung, aber in dem verlinkten Artikel ist davon nicht die Rede, sondern vom Gegenteil (außer, die .2 macht einen Unterschied - laut Lucene-Doku aber nicht):

"The currently (starting from ZF 1.6) supported Lucene index format versions are 1.4 - 2.3."

Mal schauen, ob jemand ähnliche Erfahrungen hat. Kann man evtl. die Optimierung, die FS 4.2 vornimmt, ausschalten? Was ist den außer den dokumentierten Parametern am FS-Spider noch zu drehen?

[feddersen]

Da hat mich wohl der fette Text darunter abgelenkt.

Soweit ich weiß wird ein ganz normaler Lucene-Index erzeugt, ohne irgendwelche eigenen Optimierungen. Mit Luke und den Java-Libraries sollte der Index auch ohne Probleme zu lesen sein, dass ist bei Ihnen wohl auch so?

[arnbae]

Ja, zumindest mit Luke kann ich darauf zugreifen - ich habe also keinen Grund zur Annahme, dass der von FS erzeugte Index fehlerhaft ist. Mir fiel allerdings auf, dass der von FS 3.1 erzeugte Index aus vielen Segmenten bestand (also nicht optimiert war), der in FS 4.2 erzeugte ist es hingegen.

Die Frage nach den "Stellschrauben" bezieht sich auf die Möglichkeit, dass vielleicht das Framework mit den Optimierungen nicht klar kommt, aber das ist auch ein Strohhalm.

[feddersen]

Also ich habe vor einiger Zeit mal einen Prototypen gebaut, bei der der Lucene-Index einem Java basierten Framework untergeschoben wurde. Das erwartete einen Standard-Lucene-Index, was auch ohne Probleme funktionierte. Würde ebenfalls dafür sprechen, dass der Index an sich in Ordnung ist. Vielleicht bauen Sie sich mit den mitgelieferten Lucene-Beispielen mal einen kleinen Index (unter 2.3) und versuchen diesen per Zend_Framework auszulesen. Ich könnte mir auch noch vorstellen, dass ZF nicht mit allen Feldtypen klar kommt, dass war jedenfalls in den Anfangszeiten so.

[feddersen]

Hallo Herr Bär,

haben ihre Nachforschungen noch etwas ergeben? Konnten Sie das Problem lösen oder zumindest die Ursache feststellen?

[arnbae]

Hallo Herr Feddersen,

nein, keine Fortschritte bis jetzt, aber die Zend-Library verhält sich beim Lesen des Index so unberechenbar, dass ich die Schuld dort vermute, nicht beim Index selbst. Wir erzeugen jetzt statt dessen ein XML-File aus den FS-Inhalten (Iteration über Dokumente und Felder, und Ausgabe mit getSearchableText()). Wenn PHP dann den Index selbst aus dem XML aufbaut, passt alles.

Ein Bugticket bei Zend ist bis jetzt unbeantwortet geblieben.

[arnbae]

War mich allgemein ärgert ist vor allem die Tatsache, dass ZF den Index des FS 3.1-Spiders lesen konnte, den von 4.2 aber nicht mehr. Liegt sicher daran, dass die verwendeten Libraries nun neuer sind, und vielleicht neuere Features in den Index einbauen.