Widersprüchliche Aussagen in Ext Doku zu effectively_installed()

[LukeWCS]

Hallo

Thema Frühjahrsputz und Migration, es geht um die Funktion effectively_installed(). Soweit ich das verstanden habe, ist das eigentlich nur dann notwendig, wenn man bei der Installation einer Ext und der Ausführung der Migration eine alte 3.0 Installation bzw. besser gesagt eine alte 3.0 DB berücksichtigen muss. In der 3.1+ Ära ist das aber "eigentlich" nicht notwendig, wenn man keine 3.0 Strukturen mehr berücksichtigen muss. Allerdings finden sich hierzu widersprüchliche Informationen in der Ext Doku.

Im Kapitel "Extensions » Tutorial: Migrations":

https://area51.phpbb.com/docs/dev/3.3.x ... migrations

Dort heisst es:

The effectively_installed() method is used primarily to help transition from a previous database installer method (such as a MOD that used UMIL) to migrations. However, we recommend using it all the time to ensure safer migrations.

Im separaten Kapitel "Migrations » Getting started":

https://area51.phpbb.com/docs/dev/3.3.x ... arted.html

Dort heisst es:

If it returns true, the Migration is marked as installed without applying any changes. This function is not required and typically should not be needed. This is only needed if you are trying to allow updates from a system that may currently be installed, but where migrations haven’t been run yet (e.g. updating a mod from 3.0.x to 3.1.x).

Es geht um exakt die gleiche Funktion, aber mit gegensätzlichen Aussagen. Weiss jemand näheres, bzw. weiss jemand welcher Abschnitt denn nun gültig ist? Technisch sehe ich keinen Grund mehr, weiterhin effectively_installed() zu benutzen, wenn es keine 3.0 Vorgeschichte gibt.

[Mike-on-Tour]

Welcher Abschnitt nun gültig ist, weiß ich auch nicht.
Ich habe die Funktion effectively_installed() bisher immer in der ersten Migrationsdatei meiner Extensions verwendet, um zu prüfen, ob eine durch diese Datei eingerichtete config-Variable bereits existiert. Aber eigentlich auch nur auf der Grundlage der ersten von dir zitierten Textstelle, um sicher zu gehen, weil ja eigentlich das Migrations-Tool prüft, ob die jeweilige Migrationsdatei bereit sin der Migrations-Tabelle enthalten und fehlerfrei durchlaufen wurde.

[LukeWCS]

@Mike
Du hast genau die gleichen Schlüsse gezogen wie ich.

Ich habe die Funktion effectively_installed() bisher immer in der ersten Migrationsdatei meiner Extensions verwendet, um zu prüfen, ob eine durch diese Datei eingerichtete config-Variable bereits existiert.

Exakt. Und rein technisch "würde" diese Funktion auch überhaupt nur im ersten Migrations-Schritt einen Sinn ergeben. Denn nur dort hat diese Funktion eine technische Berechtigung und zwar dann, wenn es eine 3.0 Vorgeschichte gibt. Darum schrieb ich "würde". Wenn es jedoch keine 3.0 Vorgeschichte gibt, ist diese Funktion technisch gesehen eigentlich auch im ersten Schritt nicht notwendig.

Aber eigentlich auch nur auf der Grundlage der ersten von dir zitierten Textstelle, um sicher zu gehen, weil ja eigentlich das Migrations-Tool prüft, ob die jeweilige Migrationsdatei bereit sin der Migrations-Tabelle enthalten und fehlerfrei durchlaufen wurde.

Genau das ist der springende Punkt. Vorausgesetzt man definiert einen präzisen Migrationspfad. Macht man das nicht, kann sowas wie bei Mail to post passieren.

Ich hatte mich schon damals - als ich mit der Ext Entwicklung anfing - mit diesem Detail befasst, als der Punkt Migration relevant wurde. Jetzt habe ich mich damit genauer beschäftigt. Unter anderem habe ich auch in meinem Archiv nachgeschaut ob ich Exts finde, die das weglassen. Das ist der Fall, z.B.:

Contact Admin (Rich)
phpBB.de - External Image as Link (Crizzo, Elsensee)
Customize first post edit permissions (gn#36)
Privacy protection (tas2580)

[oxpus]

Nun, die Abhängigkeiten der Migrationen einer Extension untereinander werden zwar mit der Funktion depends_on() dargestellt, welche auch genutzt werden kann, ob z. B. das phpBB einen bestimmten Versionstand besitzt oder andere benötigte Extensions vorhanden sind.
Diese Funktion definiert somit eine "Reihenfolge", in der die Migrationen ausgeführt werden sollen.
Bei "kleineren" Extensions kann man auf diese Funktion sowie auf die Funktion effectively_installed() verzichten.

Das Fehlen der Prüfung mit der Funktion effectively_installed() macht es aber schwerer, ein sauberes Updates einer Extension bereitzustellen.
Daher würde ich zumindest mit dem ersten Update diese Funktion immer empfehlen.
Denn:
Ist diese Funktion effectively_installed() "WAHR", wird die gesamte restliche Migrationsdatei ignoriert.
Andernfalls wird zunächst geprüft, ob die Funktion depends_on() vorhanden ist und diese dann ausgeführt, bevor erst danach der Rest der Migration ausgeführt oder eben ignoriert wird.

Und das kann bei umfangreichen Extensions schnell zu Timeouts bei der Installation oder einem simplen Update führen.
Ich erlebe das nämlich bei der Download Extension auch immer wieder, wenn diese zu viele ältere Releases unterstützt. Dann muss ich zwangsweise immer wieder ältere Zweige komplett entfernen, um eine Neuinstallation möglichst fehlerfrei gewährleisten zu können.
Gerne würde ich den gesamtem Migrationsbaum der Extension ab 7.0.0 mitliefern, aber die Ausführung der mittlerweile sehr zahlreichen Migrationen führt bei "langsameren" Systemen meist zu Timeouts, also Abbrüchen.
Wobei ich hierbei eher Optimierungspotential im Migrations-Controller des phpBB erwarten würde, als einen Extension Autor zu "schlankeren" Migrationsbäumen zu bewegen, aber das ist ein anders Thema...

[LukeWCS]

@Oxpus

Was die Funktion macht, ist generell klar. Ich habe für meine Untersuchungen etliche Debugs eingebaut um verfolgen zu können, was da während der Migration passiert. Der Punkt ist, um eine saubere Installation zu verwalten, braucht phpBB diese Funktion nicht, weil in der Migrations-Tabelle bei jedem erfolgreichen Migrationsschritt, dieser explizit vermerkt wird. Hat Mike ja schon erwähnt. Und wie ich durch eigene Versuche weiss, werden die erledigten Migrationsschritte bei Reaktivierung einer Ext nicht mal angefasst, sondern, wie es sein sollte, von phpBB komplett ignoriert.

Mir geht es also darum, ob es irgendeine Ursache geben könnte, das der oben beschriebene Prozess eventuell nicht funktioniert.

Und das kann bei umfangreichen Extensions schnell zu Timeouts bei der Installation oder einem simplen Update führen.

Hehe okay, meine Exts sind alle noch winzig im Vergleich zu deiner DL Ext. Von daher bin ich wohl noch nicht zu dem "Vergnügen" gekommen, mich mit Timeouts bei der Migration herumschlagen zu "dürfen". Aber gut zu wissen, dass das ein Problem sein kann. War mir bisher nicht bewusst, danke für die Info.

Wobei ich hierbei eher Optimierungspotential im Migrations-Controller des phpBB erwarten würde, als einen Extension Autor zu "schlankeren" Migrationsbäumen zu bewegen, aber das ist ein anders Thema...

Das würde ich exakt genauso sehen. Probleme müssen gelöst werden, nicht umgangen. ^^ Da gibt es auch einige "interessante" Ansichten auf anderen Gebieten, wie z.B. bei einem gemeldeten Bug von phpBB 3.3.0 (gemeldet von einem Kollegen) dass im Debug Modus bestimmte Fehler nicht mehr angezeigt wurden. Die Aussage eines phpBB Devs war damals: "Dann muss man halt fehlerfreie Programme schreiben.". Wie gesagt, es ging um den Debug Modus. Nun ja, auch das ist ein anderes Thema.

edit: Ich habe das vorhin auch mal im phpbb.com Discord zur Diskussion gestellt, in der Hoffnung, dass dort vielleicht einer der Doku Autoren mitliest.

[oxpus]

Ich hatte beide Funktionen nur noch mal für alle "Einsteiger" genannt, eben auch mit dem Hinweis für mögliche Timeouts.
Ja, die Download Extension ist schon sehr umfangreich an dieser Stelle, ist aber auch schon viele Jahre alt und stetig gewachsen.
Und sie ist auch mit die umfangreichste Extension dieser Art, die ich kenne. Selbst die phpBBGallery ist deutlich "übersichtlicher".

Grundsätzlich scheint die Migration zwar fehlerfrei zu arbeiten und das Update des Forums läuft in der Regel auch ohne Timeouts durch, nur bei den Extensions soll man (wieder einmal) fleißig "optimieren".
Dabei enthält der Core-Code noch sehr viele Stellen, die verbessert werden könnten, insbesondere die gesamte Migration.
Allein die Versionsnummer einer Extension in der Config-Tabelle zu aktualisieren (einer der Hauptgründe für den Einsatz einer neuen Migrationsdatei), braucht bereits unverständlicherweise sehr viel Zeit.
Das hätte mit Einsatz eines Caches für die Migration besser gelöst werden können, aber Symfony sei Dank muss ja alles "verkompliziert" werden

Wie dem auch sei:
Bei den Migrationen gibt es auf jeden Fall Optimierungspotenzial.
Ich hatte vor einiger Zeit dazu eine Anfrage im Ticker entdeckt, welche die Migrationsgeschwindigkeit explizit ansprach. Dieses Ticket wurde jedoch fast umgehend wieder geschlossen mit dem Hinweis, man sollte doch eher die Extension optimieren und die Coding-Vorgaben einhalten.
Ja, die Vorgaben führen ja eben ohne das Abschneiden von ganzen Migrationszweigen in der Download Extension zu besagtem Timeouts.
Schade nur, dass das damalige Thema nicht mehr auffindbar ist?!?

Aber zurück zum Thema, ich schweife massiv davon ab...

[LukeWCS]

Ja, die Download Extension ist schon sehr umfangreich an dieser Stelle, ist aber auch schon viele Jahre alt und stetig gewachsen.
Und sie ist auch mit die umfangreichste Extension dieser Art, die ich kenne. Selbst die phpBBGallery ist deutlich "übersichtlicher".

Es gibt noch ähnlich schwere Kaliber. Ich habe zwar selbst kein Bedarf für die DL Ext, sie ist aber trotzdem Stammgast im Testparcours von Ext Check (siehe Sig). Und zwar um die Robustheit zu prüfen und ggf. zu optimieren. Vor allem am Anfang war EC nicht in der Lage solch schwere Kaliber verarbeiten zu können, zum einen weil das RegEx von PHP selbst die Krätsche gemacht hat und sogar CodeSniffer in die Knie ging. Es hat ein bisschen gedauert und viel Ursachenforschung gekostet, bis ich diese Probleme lösen konnte. Also von daher, ist bei mir DL Ext quasi immer mit von der Partie.

Grundsätzlich scheint die Migration zwar fehlerfrei zu arbeiten und das Update des Forums läuft in der Regel auch ohne Timeouts durch, nur bei den Extensions soll man (wieder einmal) fleißig "optimieren".

Ich hatte ja oben geschrieben, dass ich eigene Versuche gemacht hatte, die waren teilweise aber schon länger her. Ich habe das vorhin nochmal wiederholt um zu sehen, ob ich mich richtig erinnere. Ja, phpBB fasst eine erledigte Migrationsdatei tatsächlich nicht mehr an. Das heisst es wird da noch nicht mal effectively_installed() ausgeführt, sondern phpBB ignoriert erledigte Migrationsdateien komplett. Daher vermute ich, dass das bei der DL Ext eher ein Problem mit der schieren Anzahl von Migrationsdateien ist, weniger mit der Ausführung des Codes. Das allerdings würde effektiv auf eine Schwäche des Systems (phpBB) hindeuten.

Allein die Versionsnummer einer Extension in der Config-Tabelle zu aktualisieren (einer der Hauptgründe für den Einsatz einer neuen Migrationsdatei), braucht bereits unverständlicherweise sehr viel Zeit.

Was das betrifft, wäre vielleicht das folgende eine Alternative für dich, das würde schon mal Migrationsdateien unnötig machen, die nur dazu dienen, die Version hochzusetzen.
viewtopic.php?p=1413033#p1413033

Wie dem auch sei:
Bei den Migrationen gibt es auf jeden Fall Optimierungspotenzial.

Es gibt so einige Baustellen. Aber ernsthaft, ich bin froh, dass das Ext System eingeführt wurde. Nie wieder Mods. Ich habe früher (lange vor phpBB) für ein "Konkurrenzprodukt" jahrelang Mods entwickelt und davon etliche. Daher kenne ich die Mod Problematik gut. Und so nebenbei konnte ich phpBB erst ernst nehmen, als das Ext System eingeführt wurde. Das war für mich Grundvoraussetzung um überhaupt mit phpBB anzufangen. Andere Forensoft hat sowas schon fast 10 Jahre vorher gehabt, die war allerdings auch nicht kostenlos, das muss man fairerweise dazu sagen.

Aber zurück zum Thema, ich schweife massiv davon ab...

Alles gut von meiner Seite, bei dem Thema muss man etwas weiter ausholen, weil da viele Dinge "nebendran" relevant sind oder sein können. Es geht ja um Ursachenforschung in dem Fall.

[oxpus]

Aber ernsthaft, ich bin froh, dass das Ext System eingeführt wurde. Nie wieder Mods.

Oh ja, das ist wahr...

Was das betrifft, wäre vielleicht das folgende eine Alternative für dich, das würde schon mal Migrationsdateien unnötig machen, die nur dazu dienen, die Version hochzusetzen.

Danke, aber das wäre für die Extension nicht ausreichend.
Es geht dabei nicht nur rein um das Erhöhen der Versionsnummer, sondern die Versionsnummer wird ebenfalls als Prüfmerkmal verwendet.

Aber warum eigentlich eine Alternative bei der Anzeige im ACP?
Die Anzeige der Extension-Versionsnummer braucht es doch bereits keine Migrationsdatei, denn die Versionsnummer wird aus der composer.json verwendet, unabhängig der Eintragungen in der Datenbank.
Oder war damit gemeint, diese Versionsnummer innerhalb der Extension zu verwenden?
Das geht klar dann mit dem Auslesen der composer.json über eine "einzeilige" Funktion, die man überall verwenden könnte.

Ich habe zwar selbst kein Bedarf für die DL Ext, sie ist aber trotzdem Stammgast im Testparcours von Ext Check (siehe Sig). Und zwar um die Robustheit zu prüfen und ggf. zu optimieren. Vor allem am Anfang war EC nicht in der Lage solch schwere Kaliber verarbeiten zu können, zum einen weil das RegEx von PHP selbst die Krätsche gemacht hat und sogar CodeSniffer in die Knie ging.

Oha, okay, das ist ja auch mal interessant zu wissen.
Ehrt mich, dass die Extension als "Benchmark" verwendet wird und damit geholfen werden kann, die Prüfsuite zu verbessern.
Ich hatte zwar mich auf das Angebot für die Prüftools nicht "beworben" (an dieser Stelle Danke für das ursprüngliche Angebot) und nutze aktuell "nur" die Prüfungen per Actions auf Github.
Aber dass die Download Extension PHP-regEx und gar den Codesniffer aushebelten...
Sachen gibt's...

[LukeWCS]

Oder war damit gemeint, diese Versionsnummer innerhalb der Extension zu verwenden?

Genau. Udo und ich sowie andere nutzen die Version für die Anzeige im ACP Modul.

Aber dass die Download Extension PHP-regEx und gar den Codesniffer aushebelten...

Ja, erst nach Anpassung konnten auch solche Schwerlasten wie deine Ext verarbeitet werden. Also um Benchmark geht es weniger, es geht effektiv darum zu prüfen, ob das überhaupt verarbeitet werden kann. Und bei deiner Ext muss man ohnehin ein bisschen Geduld haben, da braucht EC dann auch schon mal anderthalb Minuten.

[LukeWCS]

Ich habe mich bei LFWWH dazu entschlossen, die Funktion effectively_installed() nur noch im allerersten Migrationsschritt zu benutzen. Aber technisch gesehen sehe ich keinen triftigen Grund diese Funktion in der 3.1+ Ära einzusetzen, basierend auf meinen Versuchen. Diese Funktion macht die Handhabung der Migration nur unnötig umständlich, weil ein zusätzliches Prüfmerkmal benötigt wird. Sollte ich entsprechend neue Erkenntnisse bekommen, zum Beispiel im Zuge der Validierung von LFWWH, werde ich das hier im Thema bekanntgeben.

edit: Ich habe die Frage jetzt auch auf .com gestellt in der Hoffnung, dass dort die Ext Doku Autoren das lesen und beantworten. Auf Discord gab es exakt 0 Antworten zu der Frage.