Solr-gestützte ISFDB – Teil #8: Upgrade auf Solr 3.1

Dies ist Teil 8 einer (nicht enden wollenden?) Artikelserie über das Indizieren und Durchsuchen der ISFDB.org-Daten mit Solr. Ich bin…

Dies ist Teil 8 einer (nicht enden wollenden?) Artikelserie über das Indizieren und Durchsuchen der ISFDB.org-Daten mit Solr.

Ich bin diese Woche ein wenig im Rückstand, weil ich die Lucene / Solr 3.1 Version getestet und optimiert habe. Daher habe ich nicht viel Zeit, um meine ISFDB-Suche um neue Funktionen zu erweitern, aber dies schien mir der perfekte Zeitpunkt zu sein, um sie auf Solr 3.1 zu aktualisieren.

(Wenn Sie zu Hause mitarbeiten möchten, können Sie den Code auf github auschecken. Ich beginne mit dem Tag blog_7 und werde im weiteren Verlauf des Artikels auf bestimmte Commits verweisen, in denen ich etwas geändert habe, bis hin zum Tag blog_8, der das Endergebnis dieses Artikels enthält).

Vorhersagen

In einer perfekten Welt sollte ein Upgrade von Solr 1.4.1 auf Solr 3.1 trivial sein. Die meisten Benutzer sollten keine expliziten Änderungen an der Art und Weise, wie sie Solr verwenden, vornehmen müssen, um die gleiche Funktionalität zu nutzen, aber Änderungen können wünschenswert sein, um neue Funktionen (oder verbesserte Leistung) zu nutzen. Und natürlich: Wenn Sie wirklich fortgeschrittene Dinge mit Solr tun (wie z.B. benutzerdefinierte Plugins), werden Sie manchmal feststellen, dass subtile Änderungen erforderlich sind.

Daher gehe ich davon aus, dass ich in der Lage sein werde, Solr zu aktualisieren, indem ich einfach die neue War-Datei austausche. Das Einzige, was ich mit Sicherheit kaputt machen werde, ist meine Benutzeroberfläche. Ich habe nämlich in meinem letzten Blogbeitrag entdeckt, dass Solr 1.4.1 und Solr 3.1 unterschiedliche Versionen von jQuery verwenden, und anstatt meine eigene Kopie zu verwenden, habe ich diese Version direkt wieder verwendet. Aber (Daumen drücken) das sollte die einzige Änderung sein, die nötig ist.

Ich gehe also davon aus (ohne einen Blick in meine build.xml- oder Konfigurationsdateien zu werfen), dass die Gesamtzahl der Zeilen, die ich für das Upgrade von Solr ändern muss, zwischen 2 und 10 liegen wird.

Starten Sie das Upgrade

Wenn ich mir meine build.xml ansehe, habe ich bereits eine Parametrisierung nach Versionsnummer vorgenommen, so dass es hoffentlich ausreicht, die Option apache.solr.version variabel ist alles, was ich tun muss, um die neue Version herunterzuladen.

Als nächstes rufe ich „ant clean fetch extract“ auf und für den Anfang sieht es ziemlich gut aus.

Als nächstes werfe ich einen Blick in die Datei work/apache-solr-3.1.0/CHANGES.txt, insbesondere in den Abschnitt „Upgrade von Solr 1.4“, um zu sehen, ob es etwas gibt, das ich beachten sollte. Eine Sache, die mir auffällt (und an die ich mich als Solr-Entwickler wirklich hätte erinnern sollen, bevor ich meine Vorhersage getroffen habe), ist dies…

* The DataImportHandler jars are no longer included in the Solr
  WAR and should be added in Solr's lib directory, or referenced
  via the <lib> directive in solrconfig.xml.

Das habe ich völlig vergessen. DIH, das immer als Plugin betrachtet wurde, ist nun standardmäßig nicht in den Krieg einbezogen. Ich bin schon weniger zuversichtlich, was meine Vorhersage angeht.

Na ja, ein kleiner Rückschlag, um den ich mich kümmern werde, wenn er ein Problem verursacht. Ansonsten sieht alles gut aus. Es geht also weiter mit „ant run-solr“ und … eine Katastrophe …

build:
     [copy] Copying 23 files to /home/hossman/lucid/isfdb/work/isfdb-solr-home
    [mkdir] Created dir: /home/hossman/lucid/isfdb/work/isfdb-solr-home/lib
     [copy] Copying 1 file to /home/hossman/lucid/isfdb/work/isfdb-solr-home/lib

BUILD FAILED
/home/hossman/lucid/isfdb/build.xml:180: /home/hossman/lucid/isfdb/work/apache-solr-3.1.0/contrib/velocity/src/main/solr/lib not found.

Velocity Contrib ist tot, es lebe Velocity!

Offenbar haben wir (die Solr-Entwickler) es versäumt, dies im Abschnitt „Upgrading“ zu dokumentieren, obwohl es weiter unten in den detaillierten Änderungen aufgeführt ist…

* SOLR-1957: The VelocityResponseWriter contrib moved to core.

…da es kein Contrib mehr ist und jetzt Teil der Kern-Solr.war ist, kann ich die „Kopie“, die ich in meiner build.xml hatte, entfernen, um diese Jars zu erhalten. Danach kann „ant run-solr“ die Ant-Setup-Arbeiten ausführen und Solr starten.

Ein Mitarbeiter zieht ein, ein anderer zieht aus

Jetzt muss ich mich der Musik über DIH stellen. Zum Glück ist es wirklich einfach, im Wesentlichen das Gegenteil von dem, was ich für Velocity geändert habe, außer dass alle Solr-Beiträge jetzt etwas sauberer sind, wenn es darum geht, das eigentliche contrib jar in das „dist“-Verzeichnis zu legen.

Jetzt startet Solr ohne Probleme, und ein vollständiger Import läuft problemlos. Alle Dokumente werden problemlos indiziert und die Benutzeroberfläche funktioniert immer noch, obwohl die jQuery-Debugging-Links (wie erwartet) nicht funktionieren. Auch das ist leicht zu beheben.

Fazit (vorläufig)

Und damit ist diese neueste Ausgabe des blog_8-Tags abgeschlossen.

git diff wird Ihnen sagen, dass sich zwischen den Tags „blog_7“ und „blog_8“ nur 3 Zeilen Code geändert haben, aber das ist wegen der Änderung der Velocity-Libs im Vergleich zu den DIH-Libs ein wenig geschummelt. Was als Änderung in einer Zeile gezählt wird, war in Wirklichkeit „3 löschen, 3 nicht verwandte Zeilen hinzufügen“, was meine Gesamtzahl auf 8 (3 – 1 + 3 + 3) erhöht. Das liegt immer noch im Rahmen meiner Vorhersage, aber ich bin enttäuscht über die Änderungen an den Libs, die ich vergessen hatte. Auf jeden Fall hoffe ich, dass ich in meinem nächsten Beitrag wieder auf den richtigen Weg komme, um neue Funktionen hinzuzufügen … wann immer ich die Gelegenheit habe, daran zu arbeiten.