Neu JTL Shop 4 - Plugin SQL Procedure

[broesHPB]

Ahoi!

Aktuell passe ich gerade ein Custom-Plugin für den JTL Shop 4.06 (Build 17) an und erstelle eine neue Version des Plugins mit SQL:

DELIMITER $$

DROP PROCEDURE IF EXISTS my_procedure$$

CREATE PROCEDURE my_procedure()
BEGIN
    IF NOT EXISTS((SELECT *
                   FROM information_schema.COLUMNS c
                   WHERE c.TABLE_SCHEMA = 'datenbank_name'
                     AND c.TABLE_NAME = 'tabellen_name'
                     AND c.COLUMN_NAME = 'spalten_name')) THEN ALTER TABLE tabellen_name
        ADD spalten_name BOOL NOT NULL DEFAULT FALSE;
    END IF;
END $$

CALL my_procedure()$$

DROP PROCEDURE IF EXISTS my_procedure$$

DELIMITER ;

Ich erhalte folgenden Fehler (203 = SQL Syntax Error) im Log:

SQL Fehler beim Installieren des Plugins (XYZ): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near DELIMITER $$DROP PROCEDURE IF EXISTS my_procedure$$CREATE PROCEDURE ch at line 1

Dabei ist zu beachten, wenn ich die Query ganz normal in der Console laufen lasse, dann gibt es keinerlei Probleme.

Ich habe mir mal den betreffenden Code in admin/includes/pluginverwaltung_inc.php, insbesondere die Funktionen logikSQLDatei und parseSQLDatei, die Art und Weise wie da doppelte Tabellen verhindert werden und vermerkt werden welche Plugins welche Tabellen installiert haben ist fachlich gruselig, insbesondere mit der Logik in parseSQLDatei. Jedenfalls verhindert dieses Zerhacken der SQL-Datei, dass man komplexere Datenbank-Anfragen, z. B. über Prozeduren oder Prepared Statements über SQL-Variablen nicht nutzen kann.

Zudem habe ich die Doku zum Thema Plugins inzwischen mehrfach durchforstet, ob es da besondere Regeln für die Plugin-SQL-Dateien gibt, was man da rein schreiben darf und was nicht...

Ebenso habe ich keinen HOOK gefunden, der nach der Installation einer neuen Plugin-Version nutzbar wäre, um selbst tätig zu werden. Ich müsste jetzt selbst beim Installieren irgendwo in einer Tabelle vermerken, dass es ein Update gab und dies jetzt jedes Mal checken ob die dafür notwendigen SQL-Änderungen bereits ausgeführt wurden. Das möchte ich ungern machen.

Ist das gewollt, dass man außer DELETE, CREATE, INSERT, ALTER nichts anderes in die Plugin-SQL-Dateien schreiben kann?

Gibt es eine Alternative?

Freundliche Grüße
Hape von Bröös

 

[FMoche]

Das hat überhaupt nichts mit den von dir genannten Funktionen zu tun - wie du ja selbst schreibst, wird das SQL ja ausgeführt, erzeugt nur eine Fehlermeldung beim DB-Server.
Und das wiederum hat eher was mit PDO zu tun. Siehe dazu z.B. https://stackoverflow.com/questions...cedure-containing-a-delimiter-in-php-with-pdo

Das kannst du umsetzen mit einer bootstrap.php in includes/plugins/<deine_plugin_id>/version/<deine_version>/ mit diesem Inhalt:

<?php

namespace deine_plugin_id;

use Shop;

/**
 * Class Bootstrap
 */
class Bootstrap extends \AbstractPlugin
{

    public function installed()
    {
        Shop::DB()->query('DROP PROCEDURE IF EXISTS my_procedure', 4);
        Shop::DB()->queryPrepared("CREATE PROCEDURE my_procedure()
            BEGIN
                IF NOT EXISTS((SELECT *
                    FROM information_schema.COLUMNS c
                       WHERE c.TABLE_SCHEMA = :dbname
                        AND c.TABLE_NAME = 'deine_tabelle'
                        AND c.COLUMN_NAME = 'deine_column')) THEN ALTER TABLE deine_tabelle
                    ADD deine_column BOOL NOT NULL DEFAULT FALSE;
                END IF;
            END",
            ['dbname' => DB_NAME],
            4
        );
        Shop::DB()->query('CALL my_procedure()', 4);
        Shop::DB()->query('DROP PROCEDURE IF EXISTS my_procedure', 4);
    }
}

Events für Plugin-Updates gibt es ab Shop 5.

Ansonsten gilt für Shop 4-Plugins aber:
Für jede der alten Versionen kannst du einzelne SQL-Files definieren, die bei der Installation alle nacheinander ausgeführt werden.

<Version nr="100">
    <CreateDate>2017-11-07</CreateDate>
    <SQL>install.sql</SQL>
</Version>
<Version nr="101">
    <CreateDate>2018-11-07</CreateDate>
    <SQL>update101.sql</SQL>
</Version>

Da kannst du in install.sql ein CREATE TABLE schreiben und in update101.sql ein ALTER TABLE ADD COLUMN - nur halt mit der jeweiligen Beschränkung auf Tabellen, die mit "xplugin_<deine_plugin_id>" beginnen.
Sobald Version 101 frisch installiert wird, wird auch das install.sql ausgeführt. Und falls Version 100 zuvor installiert war entsprechend nur die update101.sql.
Also musst du nicht nachsehen, ob da irgendwelche Columns existieren, weil du das SQL der vorherigen Version ja definiert hast.

Falls du jedoch eine fremde Tabelle manipulieren möchtest, kann ich deine obige Frage "Ist das Absicht" tlw. mit "Ja, war es damals" beantworten.

 

[broesHPB]

Hallo @FMoche,

danke für Dein schnelles Feedback.

Das hat überhaupt nichts mit den von dir genannten Funktionen zu tun - wie du ja selbst schreibst, wird das SQL ja ausgeführt, erzeugt nur eine Fehlermeldung beim DB-Server.

Vielleicht hab ich das missverständlich ausgedrückt: Das SQL ist in der Konsole ohne Fehler auf dem DB-Server ausführbar, aber nicht via Plugin-Installation. Es ist über Plugin-Installation mit der in der info.xml definierbaren SQL-Datei nicht möglich Prozeduren, Prepared Statements oder auch simple CREATE TABLE IF NOT EXISTS Anweisungen zu nutzen.

Das kannst du umsetzen mit einer bootstrap.php in includes/plugins/<deine_plugin_id>/version/<deine_version>/ mit diesem Inhalt:

Wird die bootstrap.php nur während der Plugin-Installation ausgeführt oder "immer", wenn das Plugin aufgerufen wird? Die Doku dazu hatte ich so verstanden, dass die bootstrap.php z. B. das Mapping für PSR Namespaces macht und daher immer aufgerufen wird? (Ich probiers einfach mal aus, danke.)

Falls du jedoch eine fremde Tabelle manipulieren möchtest, kann ich deine obige Frage "Ist das Absicht" tlw. mit "Ja, war es damals" beantworten.

Nein, das möchte ich nicht, nur Tabellen des betreffenden Plugins.

Da kannst du in install.sql ein CREATE TABLE schreiben und in update101.sql ein ALTER TABLE ADD COLUMN - nur halt mit der jeweiligen Beschränkung auf Tabellen, die mit "xplugin_<deine_plugin_id>" beginnen.
Sobald Version 101 frisch installiert wird, wird auch das install.sql ausgeführt. Und falls Version 100 zuvor installiert war entsprechend nur die update101.sql.
Also musst du nicht nachsehen, ob da irgendwelche Columns existieren, weil du das SQL der vorherigen Version ja definiert hast.

Im Normalfall wäre das auch der Gang der Dinge und durchaus auch sinnvoll so. Ich finde es persönlich praktischer und vor allem Zeit-sparender, wenn bei z. B. einem CREATE TABLE ein IF NOT EXISTS (was mitunter auch schon in der Plugin SQL zu Fehlern führte, weil dann die REGEX die den Tabellennamen in logikSQLDatei und parseSQLDatei rausfinden soll broken ist) dabei ist oder beim Ändern einer Tabelle vorher geprüft wird, ob die Änderung überhaupt notwendig ist, falls ich das Plugin mal aus Entwicklungsgründen komplett deinstallieren und neu installieren müsste. Das ist natürlich mein persönlicher Geschmack und erhebt keinen Anspruch auf allgemeine Richtigkeit.

Freundliche Grüße
Hape von Bröös

 

[FMoche]

Du kommt mit der reinen SQL-Lösung ohne PHP ja eh nicht weiter, weil du da den Datenbanknamen drin verwendest.
Abgesehen davon kann in Shop 4 problemlos in meiner SQL-Datei ein Statement wie

CREATE TABLE IF NOT EXISTS `xplugin_<meine_plugin_id>_<mein_tabellenname>`...

ausführen. Das Problem bei dir ist lediglich der Delimiter, der aus im Link genannten Gründen nicht genutzt werden kann und daher einen Syntaxfehler erzeugt.

Dass die Logikprüfung ziemlicher Mist ist steht ansonsten nicht zur Debatte - das wurde ja aus gutem Grund in Shop 5 auch entfernt und auf Migrationen umgestellt.

 

[broesHPB]

Hallo @FMoche,

danke für das Feedback. Ich probiere heute noch Deinen Lösungsvorschlag mit der bootstrap.php aus und hoffe das klappt.

Freundliche Grüße
Hape von Bröös