Machen wir doch mal Laravel - Teil 2 - die Datenbank

In Teil eins haben wir uns damit beschäftigt, Laravel zu installieren und unser eigenes Stylesheet in unser eigenes, kleines Template einzubauen. Das lief bisher ziemlich unspektakulär und für diesen Moment hätten wir Laravel gar nicht gebraucht. Aktuell haben wir also unsere leere, weiße Seite und die wollen wir nun mit einer Liste von Blogeinträgen füllen. Wir haben uns noch nicht damit beschäftigt, Apache oder Nginx für die Website zu konfigurieren. Wir machen alles über den Laravel-Webserver. Für die Entwicklung reicht das völlig aus. In diesem Teil werden wir nun eine Datenbank erstellen und diese Datenbank mit 3 Testpostings füllen. Anschließend werden wir die Testpostings auf unserer Seite anzeigen lassen.

Den Datenbankserver konfigurieren

MySQL bzw. MariaDB haben wir bereits installiert und nun legen wir fest, wie unser Projekt sich mit der Datenbank verbinden soll. Die Konfiguration eines Laravel-Projektes geschieht über .ENV. Die .env-Datei befindet sich direkt im Hauptverzeichnis von larablog. Erstelle zuerst deine Datenbank namens „larablog“ in MySQL. Laravel kann das auch übernehmen, aber wir wollen ja einen sanften Übergang machen und machen zumindest am Anfang noch viele Dinge händisch.

.env
Wir tragen die Zugangsdaten unseres MySQL-Servers ein und schließen dann die Datei

Damit ist unser larablog nun schon einmal an einen MySQL-Server gebunden. Und hier, finde ich, spielt Laravel nun das erste mal einen Vorteil aus. Ich muss mich nicht mehr mit mysqli_connect() und so weiter befassen. Das ist alles quasi out-of-the-box vorhanden und funktioniert einfach. Nun benötigen wir Tabellen und Daten für unser Blog. Auch hier gilt erst einmal: Wir fangen super einfach an und bauen das ganze Thema nach und nach aus…

Migrationen (Tabellen)

Für mich ist dieser Teil immer noch der verrückteste Teil bei Laravel. Ich bin gewohnt, händisch SQL zu schreiben und dann bei Updates oder Deletes von Daten entsprechende Queries zu formulieren und/oder sogar die Daten zu validieren. Dank PDO kam PHP irgendwann in Richtung „prepared Statements“ und hat viel für die Sicherheit von Webanwendungen getan, doch Eloquent von Laravel geht noch einen Schritt weiter. Alles, was irgendwie mit Tabellen zu tun hat, wird in Klassen ausgelagert und zumindest theoretisch muss man kaum noch SQL schreiben, sondern nur noch PHP. Wichtig: Man kann auch weiter SQL schreiben, wenn man möchte. Aber wir wollen ja Features lernen, also verwenden wir nun ein ordentliches Modell.

Unsere Blogposts sollen einen Titel, ein Veröffentlichungsdatum, den Text selbst und ein Sichtbarkeits-Flag haben. Außerdem wissen wir jetzt schon, dass jeder Post von mindestens einem Autor geschrieben wurde, also verweisen wir auch schon einmal auf eine Autoren/User-Tabelle, die mindestens aus der Autor-ID und dem Autorennamen besteht.

Was die Autoren betrifft, hat Laravel schon mal vorgesorgt. Es gibt schon ein Modell namens User im Verzeichnis App. Daher erstellen wir erst mal nur das Model für die Blogposts

php artisan make:model Blogposts -m

Was passiert nun. Laravel erstellt 2 Dateien. Die eine Datei befindet sich im Verzeichnis app/Blogposts.php und die andere Datei wurde im Verzeichnis /database/migrations/ erstellt und hat den heutigen Timestamp als Dateinamen. Beispielsweise 2019_01_15_123456_create_blogposts_table.php und genau diese Datei öffnen wir nun:

In der up() Methode wird festgelegt, welche Spalten tatsächlich existieren wollen. Also erweitern wir das:

public function up()
{
Schema::create('blogposts', function (Blueprint $table) {
$table->increments('id');
$table->string('title');
$table>-longText('contents');
$table->boolean('visible');
$table->timestamps();
});
}

In der Blueprint.php gibt's übrigens die möglichen Felder. Letztendlich ensprechen diese Felder den üblichen Datenbank-Feldern. Nachdem wir also festgelegt haben, welche Felder wir benötigen, können wir die Tabelle migrieren. Du gibst nun also php artisan migrate ein. Zumindest bei mir schmiss dies allerdings einen Schwung Fehlermeldungen. Das liegt aktuell an MariaDB und kann leicht behoben werden.

Du öffnest einfach die Datei app/Providers/AppServiceProvider.php und schreibst noch folgendes in den USE-Block:

use Illuminate\Support\Facades\Schema;

Ausserdem erweiterst du die public function boot()

    public function boot()
    {
        Schema::defaultStringLength(191);
    }

Wir können nun über ein Tool wie phpmyadmin oder so etwas ähnliches Daten eintragen. Machen wir aber nicht, wir wollen bei Laravel bleiben. Wir erstellen nun also einen Seeder.

Der Seeder

Zuerst erstellen wir mit Artisan einen Seeder für die Blogposts

php artisan make:seeder BlogPostsSeeder

Damit wird eine Klasse im Ordner seeds erstellt. In der Klasse legen wir nun fest, dass 3 Blogposts erstellt werden sollen

3Posts
Wir fügen 3 Zeilen ein.

Anschließend öffnen wir die Klasse DatabaseSeeder.php und erweitern die run()-Methode.

public function run()
{
// $this->call(UsersTableSeeder::class);
$this->call(BlogPostsSeeder::class);
}

Da wir ja noch nichts in der Datenbank haben, führen wir in der Shell nun folgenden Befehl aus:

php artisan migrate:refresh --seed

Laravel erstellt nun die Tabellen und fügt die Testdaten ein. Wir haben nun also Inhalte hinterlegt. In Teil 3 lernen wir nun, wie wir zum einen diese Inhalte darstellen.

Den Quellcode von  Larablog findest du auf Github. https://github.com/marcshake/larablog

Magst du, was du liest? Dann lass mir doch eine Spende da.


Machen wir doch mal Laravel Machen wir doch mal Laravel - Teil 2 - die Datenbank Machen wir doch mal Laravel - Teil 3 Machen wir doch mal Laravel - Teil 4 - Nochmal ein wenig Styling Mein eigenes kleines Laravel Cheatsheet Mein Laravelblog
Lesezeit: 04:54 Minuten
1  

Diese Website nutzt Cookies. Inder Datenschutzerklärung steht, was mit deinen Daten hier passiert… Hab ich verstanden