onli wrote: ↑Thu Jul 13, 2023 2:08 pm
mitch wrote: ↑Thu Jul 13, 2023 12:09 am
Hätte diese Änderung im Changelog erwähnt werden sollen? man muss komplett neu trainieren und die alte Tabelle kann gelöscht werden, die nimmt ja nur ggf. viel Platz weg (ich hab sie zum Testen erstmal nur umbenannt, aber niemand scheint sie zu vermissen)
Ja, auf jeden Fall. Das hätte ins Changelog gehört. Und eigentlich hätte die alte Tabelle in die neue eingelernt werden sollen, zumindest optional. Ich habe den Bruch nichtmal prominent in meinem Blogartikel erwähnt,
https://www.onli-blogging.de/1960/Spamb ... rsion.html, nur als letzten Satz. Das überrascht mich selbst und tut mir jetzt leid.
Ist nicht wild, ich hatte Spaß an der Fehlersuche
Muss ich halt ein paar Mal klicken jetzt, bis sich der Bayes-Filter wieder eingeschwungen hat. Und ohne die 20 Moderations-Mails pro Tag hätte ich ja auch gar nicht gemerkt, dass ich irgendwelche Probleme im Blog habe. Von daher war's gut
onli wrote: ↑Thu Jul 13, 2023 2:08 pm
mitch wrote: ↑Thu Jul 13, 2023 12:09 am
Der Tabelle b8_wordlist fehlt der {$serendipity['dbPrefix']} – ist das ein behebenswerter Fehler? Das wäre ja gleich wieder ein Wechsel des Tabellennamens…
Ist der fehlende Prefix in deinem Setup ein Problem? Mein Eindruck ist, dass mittlerweile der Datenbankname selbst für die Unterscheidung zwischen Projekten benutzt wird und der Prefix so nicht mehr notwendig ist. Es würde uns die Migration der Daten sparen, der vom Plugin genutzte b8-Tabellenname ist konfigurierbar. Was meinst du?
Mich stört der fehlende Prefix nicht wirklich, ich habe eine eigene Datenbank für das Blog angelegt.
Mein Verständnis war immer, dass es Hosting-Angebote gibt, die z.B. nur eine Database zur Verfügung stellen und dann müssen sich ggf. Blog, Forum und Mailserver die gleiche Datenbank teilen. Damit das funktioniert, hat sich dann jemand gedacht "wenn jede Anwendung einen Präfix vor ihre Tabellen, Indizies usw. schreibt, kommt sich ja niemand ins Gehege".
Wenn das jemand in dem Kontext benutzt, wird ihn der fehlende Präfix vermutlich stören.
Bei mir mit einer eigenen Database pro Anwendung (ich bin root, ich kann so viele anlegen, bis die Platte voll ist) oder bei Dir mit sqlite (da gibt's dann auch eine Datei bzw. einen Ordner pro Anwendung vermute ich mal?) dagegen ist das eher egal.
onli wrote: ↑Thu Jul 13, 2023 2:08 pm
mitch wrote: ↑Thu Jul 13, 2023 12:09 am
- Sollte das im Plugin in der Tabellendeklaration korrigiert werden?
- Oder sollte lieber der PHP-Code so angepasst werden, dass er nur mit Kleinbuchstaben arbeitet? Dafür müssten vermutlich am Anfang alle Tokens des Kommantartextes lowercased werden und anschließend auch alle aus der Datenbank gelesenen Tokens.
Da ich das Problem auf SQLite nicht beobachtet habe - ich geh jetzt einfach mal davon aus, dass es nicht am unterschiedlichen Error-Reporting der Datenbankfunktionen liegt - scheint mit die Lösung über die Datenbankebene geschickter. Das ist wohl auch, was das b8-Projekt mittlerweile gemacht hat, in
https://gitlab.com/l3u/b8/-/commit/137d ... affc1e239f, wenn ich das richtig sehe
Wir könnten wahrscheinlich deinen ALTER-Befehl zu
https://github.com/s9y/additional_plugi ... es.php#L88 hinzufügen.
Davor hätte ich etwas Angst: serendipity_event_spamblock_bayes.php ist der datenbankunabhängige Teil, es gibt in b8/storage spezifische Klassen abhängig vom ausgewählten Backend. Ich kann nicht einschätzen, ob dieses Collate-Zeugs MySQL-spezifisch ist oder mit SQLite auch funktioniert. Vermutlich müsste man dann die Tabellen-Erzeugung mit den die DB-Backends verlagern. (Ah - das stimmt wohl, denn der Commit aus b8 bezieht sich explizit nur auf MySQL.)
Wie man eine Migration mit dem Alter-Statement baut, weiß ich auch nicht (man will das ja nicht bei jedem Aufruf wiederholen). Anders als bei s9y selbst gibt's für die Plugins kein Standardvorgehen für DB-Änderungen, oder?
Außerdem habe ich keine Chance, das zu testen (also ich kann live auf meinem Blog was machen, aber ich kann weder die anderen Backends testen noch wiederholte Neuinstallationen oder Updates durchführen).
Ich fürchte, das ist eine Nummer zu groß für mich :-/
Von daher ist es vielleicht doch einfacher, im PHP an allen Ecken und Enden lowercase-Aufrufe einzustreuen, dann muss man an die DB nicht ran (aber wenn man die DB nicht migriert, muss man nach jedem Lesen aus der DB erst einmal jedes Token lowercasen, hmmm…).