SQL Daten für ein Modul installieren?

[maxi62]

Hi,
mal ne grundsätzliche Frage. Ich hab ein Modul programmiert das eine Datenbank braucht in der bereits ca. 40 Datensätze drin sein müssen. Die Datenbank erstelle ich in der database.sql im Modulverzeichnis. Aber wie kann ich dafür sorgen das diese 40 Datensätze bereits bei der Installation eingetragen werden?

[lindesbs]

TL / Contao unterstuetzt eine runonce.php. Also eine Datei, die im TL_ROOT geschrieben wird. In dieser kannst du deinen SQL-Import machen. Nach der Ausfuehrung wird die Datei automatisch geloescht.
Oder du hast in deinem Modul einen Check, ob die Daten in der Tabelle existieren, wenn nicht, machst du einen Insert.

[maxi62]

Hi
Danke das ging flott! Das mit runonce.php ist guter Tipp, kennst du ein Modul das das bereits macht? Würde ich mir gern mal anschaun.
Ich dachte eine SQL Anweisung in Database.sql geht auch, aber scheint nicht so zu sein, hatte es probiert.

[lindesbs]

Beispiele nicht wirklich, aber erstelle einfach die Datei in system/runonce.php (das system hatte ich vergessen)

Fuer mehr Infos, muesste ich mal die Suchmaschinen nutzen

[BugBuster]

Ich habe mir mal eine gesichert die per Liveupdate mit kam, liegt aber zu Hause.

nachtrag: ich wusste doch ich hab das schon mal erzählt:

<?php @error_reporting(0); @ini_set("display_errors", 0); 
 
// Update database
$objDatabase = Database::getInstance();
 
try { $objDatabase->execute("INSERT INTO `tl_tcplz` (`geo_id`, `geo_staat`, `geo_bundesland`, `geo_reg_bezirk`, `geo_landkreis`, `geo_vzs`, `geo_ort`, `geo_lg`, `geo_bg`, `geo_plz`) VALUES (5078, 'DE', 'SN', 'Dresden', 'Kreisfreie Stadt Dresden', '-', 'Dresden', 13.7210676148814, 51.0600336463379, '01067')"); } catch (Exception $e) { $errors[] = $e->getMessage(); }
 
?>

Ein Beispiel für ein anderes Modul.
Du solltest aber auch in der runonce testen ob die Daten schon enthalten sind, damit diese nicht mehrfach versucht werden zu installieren, falls jemand das Modul nochmal installiert (repair).

[lindesbs]

Oder es geht auch so, am Beispiel fuer die tl_log Tabelle :

<?php


class RunonceJob extends Frontend
{

    public function __construct()
    {
        parent::__construct();
    }
    
    public function run()
    {
        $arrInsert=array(
            'action'    => 'runonce',
            'text'    => 'runonce'
        );

        $this->Database->prepare("INSERT INTO tl_log %s")->set($arrInsert)->execute();
    }

}

$objRunonceJob = new RunonceJob();
$objRunonceJob->run();

?>

[maxi62]

Alles klar, danke euch!

[andreas.schempp]

Vielleicht ein kleiner Hinweis. Diese Methode ist nicht wirklich sicher, wenn man 2 module installiert die BSP von einander abhänig sind und beide diese Datei haben wird nur eine ausgeführt. Die andere wird überschrieben.

Das kann allerdings nur passieren wenn die Erweiterung eine Abhängigkeit hat, oder? Das muss der Entwickler dann wohl berücksichtigen. Wir nutzen die runonce.php beim Isotope eCommerce sehr stark, da die Datenbankstruktur sich immer wieder anpasst. Beispielsweise wurde zwischen 0.1.0 beta und 0.1.0 stable nahezu alle Tabellen umbenannt. Das hat die runonce.php gemacht ohne dass Daten verloren gingen.

[lindesbs]

Die runonce.php wird in der system/initialize.php getriggert. D.h. Die Module werden ausgepackt, wahrscheinlich in Reichenfolge der dargestellten Liste im BE.
D.h. wenn isotope eine runonce erstellt und danach die taxonomy (als Beispiel) auch eine, wird die isotope ueberschrieben.
Nach dem folgenden Reload der Seite (Oder wenn zw. ein FE Aufruf oder BE Aufruf erfolgt (auch ajax) wird die runonce ausgefuehrt.

Es muesste also eine Moeglichkeit geben, modulabhaengige runonce´s zu generieren, die dann abgearbeitet werden. Koennte auch in Kombination mit diesem Ticket erfolgen (http://dev.contao.org/issues/1657)

[lindesbs]

Doch, mit der 2.9 koennen mehrere Module gleichzeitig geupdated und nachinstalliert werden. DANN wird es definitv ein Problem werden, da der ER CLient in der 2.9 fuer jedes installierte Modul eine CheckBox setzt, egal ob ein Update notwendig ist, oder nicht.
Somit ist die Nutzung der runonce eine schlechte Idee... Mein Hinweis im Bugtracker wurde geclosed (http://dev.contao.org/issues/2087)


Eine andere Moeglichkeit habe ich hier beschrieben : http://www.contao-community.de/showt...ll=1#post55568

[lindesbs]

Mir ist aber gerade noch eine bessere sicherere Methode eingefallen.
lege einfach eine runonce.php in dein config Verzeichnis. deine config.php mit einer eigenen kontrolle auf Vorhandensein der Datei pruefen, ausfuehren und fertig.

Dann schlaegt das globale runonce Problem nicht mehr zu.

Ich werd dies mal im Wiki beschrieben.

[lindesbs]

So, hier kann man nachlesen, wie man dies durchfuehren kann : http://de.contaowiki.org/Runonce#Mod...te_runonce.php

[BugBuster]

Das ja cool
Sowas ähnliches hatte ich mal in einer meiner Module, aber direkt in der Modul Klasse um eventuelle Migrationen durchzuführen. Damals hatte ich das Problem, das die runonce.php zu früh aufgerufen wurde, da war das einlesen und anlegen der DB Felder noch gar nicht durchgeführt worden.

[mac123]

Hallo,
ich habe die runonce.php in mein Modul gepackt, trotzdem wird der Insert in die Datenbank nicht richtig ausgeführt. Ich vermute mal, bevor die DB existiert.
Wenn ich die runonce.php später in den Modulordner kopiere (nachdem das Modul installiert ist), werden auch die Daten in die DB geschrieben.
Hat da jemand einen Tipp für mich, was ich tun kann?

Gruß
Mac123

[xtra]

if($this->Database->fieldExists('meinFeld', 'tl_something', true)
{
  // unsere Felder sind da, wir koennen eintragen.
  $this->Database->execute('INSERT INTO tl_something ....');
  // anschliessend kann die runonce geloescht werden.
} 

Gruss
Chris

[mac123]

Vielen Dank für die Antwort, Chris.

Ich habe die Abfrage in die config/config.php gepackt. Wenn ich mein Modul jetzt installieren will, bekomme ich nur eine weiße Seite
Oder muss die Abfrage und der Aufrufe für die runonce.php nicht umbedingt in die config.php?

Liebe Grüße
Mac123

[xtra]

Aus der config heraus wird das nicht klappen, zu diesem Zeitpunkt ist die Datenbank noch nicht instanziert und obendrein hast du in diesem Kontext sowieso keine Datenbank (da braeuchtest du noch einen $this->import('Database'); - jedoch rate ich hiervon ab).

Das bringt uns nun wieder auf das bootconfig problem, zu welchem wir an anderer Stelle schon diskutiert haben.
Eine bessere Stelle als die config ist nun fraglich. Die config ist im falschen Kontext.

Ich frage mich, warum du nicht lieber irgendwo im Backend, wo du deine Erweiterung bearbeiten kannst, zu beginn einen check machst ob die Datensaetze bereits da sind und ggf. dann eintraegst.
Ich denke damit bist du schneller am Ziel.
(Langsamer ginge es indem du dich von hand in die initconfig.php eintraegst, aus dieser heraus aufgerufen wirst und dann deine runonce nach obigem Schema bearbeitest - langsamer, hackish und insgesamt nicht so wirklich mein Favorit, dennoch kreativ ).

[mac123]

Hm, das erklärt alles. Sowas habe ich auch schon vermutet. Die Variante mit dem Aufruf in der config.php habe ich hier im Forum gelesen.
Ich will ein schönes Modul erstellen, deshalb werde ich es wohl ins Backend packen. Am besten wäre ein Punkt Einstellungen wo ich anklicken, welche Datensätze (Vorlagen) in die Datenbank geschrieben werden. Da ich aber neu in der Contao-Entwicklergemeinde bin, muss ich mich da erst noch reinarbeiten und Möglichkeiten suchen.

Ich bin übrigens gerade an dem Social Bookmarks Modul.


Gruß
Mac123