Veröffentlicht 16. April 201213 j Wir haben ein MediaWiki 1.18.1 unter PHP 5.3.3 auf PostgreSQL 8.4.9 laufen. Alles funktioniert soweit prima, auch die Suche allerdings tritt folgendes Phänomen auf: Es gibt im Wiki einen Artikel mit dem Titel: Urlaubsvertretung. Dieser wird auch korrekt gefunden, wenn man nach Urlaubsvertretung sucht. Sucht man allerdings nur nach Urlaub, so werden einige andere Artikel gefunden, die das Suchwort enthalten, aber eben nicht der Artikel "Urlaubsvertretung". Sucht man nach anderen Worten, die in diesem Artikel enthalten sind, so wird er völlig korrekt gefunden. Bei anderen Suchen ist ein ähnlich falsches Verhalten bisher noch nicht aufgefallen. Kennt jemand dieses Probelm und evtl. auch einen Lösungsansatz? Danke Martin
16. April 201213 j Ich kenne Mediawiki nicht im Detail, aber klingt danach, als wäre der Index nicht vollständig
18. April 201213 j Autor Leider hat ein Rebuild der Indizes nichts gebracht. Kennt evtl. noch jemand eine mögliche Ursache oder eine Möglichkeit, die Suchanfragen und Ergebnisse zu loggen?
18. April 201213 j Hast mal versucht nach "urlaub*" zu suchen? Manchmal habe ich das Gefühl, dass die Wildcard-Suche, die mediawiki haben sollte, nicht auf Seitentitel anspricht, sofern nur Teile des Titels gesucht werden.
18. April 201213 j Autor Danke erstmal für die Unterstützung. Nachdem ich mich einen Nachmittag durch die Mediawiki-Suche und die zugrundeliegenden PG-Datenbanken gewühlt habe, schaut es so aus: In der o.g. Konfiguration erfolgt die Textsuche über die Postgres-Volltextsuche. (tsearch2) Per Trigger wird beim Anlegen, Ändern usw. von Artikeln je ein tsvector für den Titel und jede Version des Artikels angelegt. Diese tsvectoren werden dann in der Volltextsuche gegen das Suchwort abgeglichen. Im konkreten Fall meines Artikels "Urlaubsvertretung" ist es nun so, dass weder im Titel noch im Text das Wort "Urlaub" als eigenes Wort auftritt sondern nur in Zusammensetzungen. (Urlaubsvertretung, Urlaubsantrag etc.) In den tsvectoren taucht somit "Urlaub" nicht als eigener Begriff auf. Ob das stemming-technisch so ok ist, kann ich noch nicht beurteilen. Ich werde als nächste mal versuchen, etwas an der Postgres-Volltextsuche zu drehen oder diese ganz zu deaktivieren, da die potentielle Artikelanzahl überschaubar bleibt.
18. April 201213 j Du kannst bei PGSQL ggf einfach Deine ganzen Vektoren neu erzeugen, eben führe einfach einmal manuall den Trigger aus.
13. Mai 201213 j Autor Wir haben jetzt im Endergebnis eine (aufgebohrte) Extension eingesetzt. Extension:RigorousSearch - MediaWiki Diese sucht unabhängig vom Postgres-Stemming, was sich als eindeutig sinnvoller erweisen hat, da wir in den Artikeln einen hohen Anteil an fach- und firmenspezifischen Begriffen haben, für die das Stemming ungeeignet war.
Erstelle ein Konto oder melde dich an, um einen Kommentar zu schreiben.