Solr-gestützte ISFDB – Teil #5: Meine Autoren ausfüllen

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

Als wir das letzte Mal gegangen sind, hatte ich grundlegende Unterstützung für mehrere Arten von Dokumenten: Titeldokumente (die ziemlich gut ausgearbeitet waren) und Autorendokumente (die nicht ausgearbeitet waren). In dieser Folge nehme ich einige Änderungen vor und verbessere die Modellierung von Autorendaten.

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

Schritt #0: Meine Unordnung aufräumen

Wie ich bereits beim letzten Mal erwähnt habe, habe ich beim Hinzufügen meiner Autorendokumente eine Abkürzung genommen, indem ich mehrere Felder in der schema.xml wiederverwendet habe, die bereits für die Titeldokumente vorhanden waren. Bevor ich weitere Felder zu meinen Autorendokumenten hinzufügte, wollte ich zunächst die bereits vorhandenen Felder bereinigen, so dass eine klare Trennung gegeben war und ich die Felder problemlos ändern konnte, ohne Gefahr zu laufen, meine anderen doc_type zu zerstören.

Ich habe also damit begonnen, alle Felder in den Konfigurationsdateien DIH und schema.xml umzubenennen, so dass die Entitäten Titel und Autor unterschiedliche Feldnamen haben, außer in den seltenen Fällen, in denen das Konzept hinter den Feldern für beide Entitätstypen wirklich dasselbe ist…

• imdb URLs
• wikipedia-URLs

Die neue Namenskonvention ist größtenteils nur eine Vereinfachung des DB-Spaltennamens, wobei die Präfixe „title_“ und „author_“ in den meisten Fällen wegfallen, da sie nicht eindeutig sind (d.h.: „Authors“ haben kein „ttype“ und), und der Wechsel zu Dingen wie „author_*s“ als Autorenlistenfelder für Titel (da sie mehrwertig sein werden, die entsprechenden Felder für Autoren jedoch nicht).

Außerdem habe ich für alle Datums- und URL-Felder die Namenskonventionen *_date und *_url (und *_urls) verwendet, um ihre Verwendung/Bedeutung deutlicher zu machen. Ein schöner Nebeneffekt dieser Änderung ist, dass die schema.xml einfacher wird, weil ich mehr dynamische Felddeklarationen verwenden kann.

Als ich diese Änderungen überprüfte, fielen mir zwei kleine Merkwürdigkeiten in meinen Dokumenten auf…

1. Alle Autorendokumente erhielten ein Feld „seriesnum“.
2. Alle Titeldokumente erhielten ein Feld „author_id“.

Das Feld seriesnum war keine Überraschung mehr, als ich mich daran erinnerte, dass ich dieses Feld mit dem Standardwert „-1“ konfiguriert hatte, als ich noch ausschließlich titelbasierte Dokumente verwendete. Um dies zu beheben, musste ich nur die Standardlogik mit einem MySQL-„IF“-Trick in die SQL-Datei übertragen.

Das Feld „author_id“ war interessanter – es stammte offenbar von der verschachtelten Entität der „zweiten Ebene“, die verwendet wurde, um die Titel/Autor-Zuordnungen für Titeldokumente zu erhalten. Dies ist eine der Situationen, in denen das Ziel von DIH, Felder, die von DataSources zurückgegeben werden, einfach zu Dokumentfeldern zu machen, kontraproduktiv ist. Ja, ich habe ein Feld „author_id“ in meinem Schema, aber ich möchte nicht, dass DIH es für diese Art von Entität verwendet. Ich habe ein paar Minuten damit verbracht, herauszufinden, wie ich das vermeiden kann – meine erste Vermutung war, dass ich das <field ... /> Syntax, um jedes gewünschte Feld zu deklarieren, um zu verhindern, dass diese impliziten Felder entstehen. Aber bevor ich so weit kam, fiel mir ein, dass, wenn ich in meiner SQL einen alternativen ‚Namen‘ verwendete, der in meiner schema.xml nicht existierte, DIH diesen (wahrscheinlich) ignorieren würde (ähnlich wie es mit mehreren Werten für Felder mit einem Wert umgeht). Es funktionierte wie ein Zauber.

Schritt #0.5: Meinen Arbeitsbereich aufräumen

Es mag wie eine triviale Kleinigkeit erscheinen, aber nachdem ich diese Feldnamen bereinigt hatte und sie funktionierten, wollte ich meine schema.xml-Datei neu organisieren, um die Felddeklarationen auf der Grundlage der Art der Dokumente, in denen sie verwendet werden, enger zusammenzufassen. Mein physischer Arbeitsbereich ist ein einziges Durcheinander – aber ich mag es, wenn mein virtueller Arbeitsbereich ordentlich und übersichtlich ist und sich die Dinge leicht finden lassen. Während ich diese Felddeklarationen neu gruppierte, fiel mir auf, dass mein Feld „catchall“ noch immer als String-Typ aus meinem ursprünglichen Schema deklariert war (was mir wahrscheinlich aufgefallen wäre, wenn ich mir den Schema-Browser kürzlich angesehen hätte). Durch die Umstellung auf „simpletext“ habe ich ein viel besseres Erlebnis, wenn ich versuche, schnell einige einfache Suchen durchzuführen.

Weiter mit der Show

Sobald die Dinge etwas übersichtlicher waren, konnte ich mich daran machen, die Modellierung der Autorendaten zu verbessern. Der erste triviale Schritt bestand darin, meinen Autorendokumenten ein paar weitere Felder hinzuzufügen – einige einfache aus der Tabelle „Autoren“ sowie neue „Webseiten“ und „E-Mails“ (unter Verwendung weiterer verschachtelter Entitäten). Dabei stellte ich auch fest, dass ich immer noch einige Felder als „multiValued“ markiert hatte, die das nicht sein sollten (egal wie sehr man aufräumt, etwas Staub schleicht immer durch).

Ich habe auch die Modellierung von Autorendaten in Titeldokumenten etwas verbessert, indem ich meine „author_*“-Felder so aktualisiert habe, dass sie speziell einen leeren Wert indizieren, wenn ein Teil der Metadaten für einen Autor NULL ist. Dies ist wichtig, wenn ein Titel mehrere Autoren hat, aber einige Daten (z.B. ein Foto) für einen der Autoren fehlen. So können wir jeden Feldwert anhand der Position in der Liste mit dem richtigen Autor in Verbindung bringen. (Solr gibt die Werte eines mehrwertigen Feldes immer in der gleichen Reihenfolge zurück, in der sie hinzugefügt wurden, und DIH fügt Felder aus verschachtelten Entitäten immer in der gleichen Reihenfolge für jedes Dokument hinzu)

Fazit (vorläufig)

Und damit ist diese neueste Ausgabe des blog_5-Tags abgeschlossen. Der Index ist jetzt in einem viel besseren Zustand und liefert viel mehr nützliche Informationen, wenn Sie nach Autoren oder Titeln suchen. Ich vermute, dass ich beim nächsten Mal in den sauren Apfel beißen und mich mit dem großen Elefanten im Raum auseinandersetzen muss: Pseudonyme.