Fragen zum Installationsvorgang von J4

  • Hallo,


    ich versuche derzeit ein Quickstart-Package für J4 (J4 Beta 5 und einige Drittanbieter-Erweiterungen, die schon unter J4 laufen) zu erstellen und zwar analog zu J3.


    Nun gibt es analog zur joomla.sql in J3 gleich 3 Dateien in J4: base.sql, extensions.sql und supports.sql


    1.Die Vorgehensweise einer weiteren sample_data_test.sql (gesamte exportierte DB) funktoniert nicht, da diese sql-Datei scheinbar keine Anwendung findet.

    Die Installation läuft normal durch, ohne die zusätzlichen Tabellen zu schreiben bzw. zu ändern.


    2. Dann die 3 sql-Dateien gelöscht und mein Script in base.sql umbenannt.

    Bei der Installtion zunächst folgender Fehler: "This comand is not supported in the prepared statemant protocol yet".

    Dann die Zeile "START TRANSACTION" in meinem Script gelöscht. Nun bleibt der Fehler aus und es werden die DB-Tabellen erstellt.


    Abschließend folgender Fehler: "Some errors occured while populating the database. No database schema exists for this database type"

    Die Installation wird nicht abgeschlossen.


    3. Zu guterLetzt habe ich die 3 originalen sql-Dateien belassen und am Ende der supports.sql (oder auch der extensions.sql) mein Script angehängt. Existierende Tabellen werden dabei gelöscht, sowie neu erstellt und gefüllt.

    Die Tabellen sind abschließend alle vorhanden. Leider erhalte ich folgenden Fehler: "Duplicate entry '212-4.0.0-2020-09-27'for key 'PRIMARY' "

    Das betrifft die Tabelle #__schema .

    Die Installation wird nicht abgeschlossen.


    Fragen:


    Wie ist das in J4 generell mit den Beispieldaten geplant?

    Soll das später einmal funktionieren wie in J3 oder funktioniert es bereits jetzt schon auf eine andere Art und Weise?

    Außer base.sql, extensions.sql, supports.sql, localise.xml gibt es da wohl irgendwie noch eine custom-Datei. Was hat es mit dieser auf sich? Ich kann sie nirgends finden.

    Auch in der entsprechenden Sprachdatei finde ich noch keine Anhaltspunkte.


    Im Moment weiß ich nicht genau, wo ich da in Hinblick auf eine Lösung ansetzen kann. Oder ist der Entwicklungsstand da noch nicht weit genug, um damit zu arbeiten?


    p.s. In der aktuellen J4 Beta6 dev scheint es diesbezüglich keine Änderung zu geben.

  • Hallo JoomlaWunder,


    Mit Qickstart-Paketen habe ich noch nie gearbeitet, kann daher auch zu obigen Fragen da nichts beitragen.

    p.s. In der aktuellen J4 Beta6 dev scheint es diesbezüglich keine Änderung zu geben.

    Wird Dir jetzt nichts helfen, aber nur zur Info:


    Änderung gab es am 4.0.0-2020-12-20.sql - nur das hier:

    https://github.com/joomla/joom…m_admin/sql/updates/mysql


    Liebe Grüße

    Christine


  • Wie ist das in J4 generell mit den Beispieldaten geplant?

    Die, entschuldigung bitte, bescheuerte Idee Sample-Daten via Plugins vom Typ "sampledata" (im Zusammenspiel mit Backend-Modul "mod_sampledata") dem User nach Installation zu überlassen.


    Das Ganze ist eine überkomplizierte, aufwändige, konfliktreiche(!) Sackgasse für komplexere Demodaten.


    Klar kann man aus so einem Plugin theoretisch auch SQL-Dateien ausführen lassen und diese userIds anpassen, Konflikte lösen etc. pp.


    aBer keine Ahnung/Hilfe. Nur Frust...

  • Zitat

    Wie ist das in J4 generell mit den Beispieldaten geplant?

    Soll das später einmal funktionieren wie in J3 oder funktioniert es bereits jetzt schon auf eine andere Art und Weise?


    Die sampledata wurden von J3 übernommen und funktionieren genau so, nur dass ein paar Datentypen dazu gekommen sind. Früher mal, in Version 2 denke ich, waren sample data in einer sql install datei.

    Aber ich würde mit so einem Plugin lieber keine sql daten importieren!


    EDIT:
    Re:Later bei Sackgasse stimme ich zu. Aber ich habe keine Möglichkeit gefunden, die sample data wieder rückgängig zu machen. Denn der Benutzer kann vor oder nach der Installation etwas verändert haben. Wenn du eine Idee hast - immer her damit.

  • Ich muss gestehen, ich habe mich mit diesem Modul noch nie beschäftigt und weiß auch gar nicht, wie es funktioniert und was es alles kann. Auf die Schnelle verstehe ich das so, dass man nachträglich aus dem Backend heraus irgendwelche Beispieldaten installieren kann. Aber womöglich gar nicht jene, welche in den sql-Dateien im Verzeichnis "installation" liegen, da das dann ja gar nicht mehr existiert?


    Aber mal unabhängig von diesem Modul:

    Da ich die komplette DB einer funktionierenden J4-Installation exportiert habe, müsste es doch irgendwie möglich sein, diese sql-Datei anstatt der base.sql, extensions.sql und supports.sql zu verwenden, also so wie in #1 unter Punkt 2 beschrieben.

    Das wäre der einfachste Weg, um ein Quickstart-Package der gesamten Installation zu erstellen.


    Was könnte denn da diesen Fehler auslösen?

    Some errors occured while populating the database. No database schema exists for this database type"

  • Ich habe jetzt eine Vermutung:

    Bei der Ausführung der base.sql wird die Tabelle #__schemas nur erstellt, aber noch nicht gefüllt (1 Eintrag).

    In meiner exportierten DB ist diese bereits gefüllt. Im weiteren Verlauf der Installation soll dann vermutlich der Eintrag vorgenomen werden, welcher nun aber bereits existiert.

    Ich werde es nochmal probieren und die Tabelle #__schemas vor dem Export leeren.

  • Zitat

    Auf die Schnelle verstehe ich das so, dass man nachträglich aus dem Backend heraus irgendwelche Beispieldaten installieren kann. Aber womöglich gar nicht jene, welche in den sql-Dateien im Verzeichnis "installation" liegen, da das dann ja gar nicht mehr existiert?

    Richtig. Es sind ganz andere Daten.


    Zu den anderen Sachen - welche Datenbank hast du? welche Version?

  • MySQL 10.4.14-MariaDB


    Die base.sql zu ersetzen scheint ein Problem zu sein.

    Aber die originalen sql-Dateien zu verwenden und meine .sql da einfach hinten ranzuhängen in einem der beiden Scripte (außer base.sql), verursachte ja den "duplicate entry". Da könnte das Entfernen von INSERT INTO ..... #__schemas eventuell doch helfen.

    Das werde ich morgen testen.

  • Aber womöglich gar nicht jene, welche in den sql-Dateien im Verzeichnis "installation" liegen, da das dann ja gar nicht mehr existiert?

    Exakt. Kannst ja mal in die plugins/sampledata/blog.php reinschauen. Eine SQL wird da nicht gezogen. Lediglich per PHP die Datenbank weiter befüllt. Deswegen meinte ich oben

    Klar kann man aus so einem Plugin theoretisch auch SQL-Dateien ausführen lassen und diese userIds anpassen, Konflikte lösen etc. pp.


    müsste es doch irgendwie möglich sein, diese sql-Datei anstatt der base.sql, extensions.sql und supports.sql zu verwenden, also so wie in #1 unter Punkt 2 beschrieben.

    Das nicht. Die Dateien müssen allerwenigstens existieren, sonst bricht die Installation ab. Ob man sie nun leer lassen kann, müsste man prüfen.


    Ich würde erst mal plump eine zusätzliche custom.sql hinterlegen mit einem unverfänglichen Einzeiler oder so. Ob die Datei ausgeführt wird. Mir scheint das so.


    Es gibt da dieses Array

    https://github.com/joomla/joom…nController.php#L143-L149


    Die Werte sind letztlich SQL-Dateien ohne sql-Endung. Wobei die custom1 und custom2 optional existieren können.


    Je nach Installationsschritt wird nach ein wenig Prüfungsgeplenkel diese Methode aufgerufen

    https://github.com/joomla/joom…el/DatabaseModel.php#L472


    die die SQL-Datei ausführt.


    So meine fiktive Interpretation des Codes :?:


    Man darf sich nicht davon irritieren lassen, dass die Dateien alle $schema oder ähnlich im Codeverlauf genannt werden. Für mich war "Schema" zuvor auch was anderes ;-) Auch die Warnmeldungen, die von Schema reden, meinen oft lediglich "Datei fehlt".

  • Ich würde erst mal plump eine zusätzliche custom.sql hinterlegen mit einem unverfänglichen Einzeiler oder so. Ob die Datei ausgeführt wird. Mir scheint das so.

    Das scheint die Lösung zu sein. In Analogie zu J3, wo man eine sample_data_ .... .sql ergänzen kann, arbeitet J4 wohl mit dieser custom.sql.

    Diese wird nach base.sql, supports.sql und extensions.sql ausgeführt, sofern sie vorhanden ist. Die Installation läuft durch und abschließend sind alle DB-Tabellen wie in meiner ursprünglichen Installation vorhanden.

    Das Backend scheint auch ohne Probleme zu laufen.


    Allerdings gibt es 2 Unterschiede zu J3:

    - START TRANSACTION muss aus der custom.sql entfernt werden -> sonst Fehlermeldung (siehe oben)

    - Und die Tabelle Schemas darf keinen Eintrag erhalten, also folgendes aus der custom.sql entfernen (beispielhaft):

    INSERT TO `#__schemas` (`extension_id`, `version_id`) VALUES

    (212, 4.0.0-2020-09-27);

    Sonst "Duplicate entry"!


    Und bei der Erstellung eines Quickstart-Package entferne ich zusätzlich diese actions-Tabellen und je nach Bedarf auch User-Tables. Die user-ids werden sauber ersetzt wie in J3.


    p.s. Nun muss ich nochmal schauen, was sich bei der Installaton ändert, wenn ich die custom.sql in die localise.xml eintrage.

  • Weitere Erkenntnisse:


    Der zusätzliche Eintrag der custom.sql in die localise.xml macht keinen Unterschied. Eine Auswahl zwischen herkömmlicher Installation und Quickstart-Package ist nicht möglich.


    Und was die Tabelle #__schemas und deren Inhalt betrifft, braucht man die gar nicht erst mitexportieren. Die wird eh über die base.sql angelegt.