Laravel, baza danych, podejście code first

Question

Hej

Uczę się Laravela i jakieś proste projekty już zrobiłem z tutoriali, Mam jednak taki plan by zrobić kolejny projekt w taki sposób, by ktoś po pobraniu z GitHub, mógł w łatwy sposób utworzyć bazę danych i wypełnić ją danymi, które wcześniej przygotuję. Czy mogę prosić o podpowiedź, jaka jest procedura, może jak workflow powinien być przy takim projekcie. A może znacie jakiś tutorial lub artykuł, który to porusza?

Czytałem o podejściu code first i database fist i na tę chwilę najpierw tworzę ręcznie bazę w phpMyAdmin i potem ją podpinałem do Laravel. Następnie używam Eloquent i komendą php artisan make:model Internal -mfsc tworzę migration, factory, seeder, i controller. Jednak w migracji widzę po utworzeniu tylko coś takiego:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('internal', function (Blueprint $table) {
            $table->id();
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('internal');
    }
};

A mam wrażenie, że w tym momencie powinienem widzieć tutaj strukturę tabeli internal? Zresztą z modelu mogę się do niej dobrać i wszystko normalnie działa. Ale takie są początki

`

Answer 1

Wydaje się, że zamieniłeś kolejność działania. Przygotowałeś najpierw ręcznie strukturę tej tabeli w bazie danych? Nie powinieneś tego robić, bo od tego właśnie są migracje. Należy dostosować wstawiony przez Ciebie kod - dodać tam po kolei kolumny jakie mają być utworzone w bazie danych. Następnie wystarczy wywołać polecenie php artisan migrate i wszystkie migracje, które do tej pory nie były uruchomione, zostaną wykonane. Możesz też później tworzyć migracje zmieniające tabele w razie potrzeby, bo nie powinieneś modyfikować już istniejących migracji. Generalnie żadnej operacji na strukturze bazy nie powinieneś wykonywać ręcznie z poziomu bazy, bo to oznacza, że jak Twój projekt pobierze ktoś kolejny, to już mu się nie odtworzy. A tak wykona tylko jedno polecenie i wszystko będzie gotowe. W razie pobrania nowych zmian wykona je ponownie i ewentualne brakujące migracje zostaną wykonane.

W dokumentacji jest to też opisane i znajdziesz tam dostępne typy kolumn, ich ustawienia itd.: https://laravel.com/docs/9.x/migrations

Comments

Właśnie mi się to musiało dziś w głowie w nocy ułożyć, bo obudziłem się z podobnym wnioskiem . Dziękuję, że mi to potwierdziłeś Natomiast powstały inne pytania.

1. Czy można w jakiś sposób z gotowej bazy danych wygenerować kod zgodny z tym, który trzeba napisać w migracji Laravel?
2. Rozumiem, że każdy plik z migracją to jakby kolejny krok w rozwoju bazy danych. Ale w jaki sposób tworzę kolejne zmiany i rozbudowę? Czy w każdym następnym pliku migracji, kopiuję to co już mam i potem do tego dodaje zmiany, czy trzymam całą historię zmian i w nowej migracji zapisuję tylko zmiany, a polecenie php artisan migrate za każdym razem odpala wszystkie migracje w sposób chronologiczny?
3. Znalazłem polecenie php artisan schema:dump, które faktycznie robi mi dump bazy (na początku były problemy bo nie miałem w PATH ścieżki o mysqldump). Jakim poleceniem Laravel (artisan) mogę odtworzyć tę bazę np. lokalnie na innym kompie?
4. Czy dobrze rozumiem, że polecenie php artisan make:seeder UserSeeder tworzy oddzielną klasę w której mogę ustawić automatyczne wpisy do bazy danych, które wypełnią bazę losowymi danymi? Czy jest to zatem taki dummy data generator?
5. W jaki sposób stworzyć klasę, która doda np. po 30 rekordów do każdej tabeli? Rozumiem, że można to zrobić za pomocą make:seder, ale jak dodać wcześniej przygotowane konkretne dane?

Zaczyna mi się podobać Laravel, ale cały czas zastanawiam się w co się mocniej zaangażować. Bo jeszcze uczę się .NET i React+Ekspress. W sumie na każdej platformie można zrobić każdy projekt. I jak tu wybrać

---

1. Laravel nie ma takiej funkcjonalności, ale są do tego biblioteki, np.: https://github.com/kitloong/laravel-migrations-generator Generalnie jednak wychodziłbym domyślnie od pisania migracji, a nie od generowania ich na podstawie bazy. Chyba że to sytuacja, gdy mamy już sporą bazę i przenosimy się na Laravela, wtedy można pomyśleć.

2. Nie, nie kopiujesz, dodajesz w kolejnych migracjach kolejne zmiany, a starych nie usuwasz. Na początku nazwy pliku z migracją jest data, po nich Laravel sortuje i wykonuje od najstarszych. Po wykonaniu w bazie powstanie oprócz Twoich tabel także tabela migrations i tam zostaną zapisane wykonane migracje. Tak więc jeśli powstaną później nowe migracje, to przy kolejnym uruchomieniu wykonają się tylko te, które się nie wykonały. I dzięki temu bez problemu można wprowadzać zmiany w bazie na wielu kopiach aplikacji.

3. Ten dump jest na sytuacje, gdy nazbierało się już bardzo wiele migracji i chce się to uporządkować generując jeden plik SQL z dotychczasowym stanem, aby móc usunąć istniejące migracje. Laravel sam wtedy ogarnia to, aby przy uruchomieniu migracji załadować najpierw ten dump: https://laravel.com/docs/9.x/migrations#squashing-migrations Jakby Ci jednak bardzo zależało, aby z jakiegoś powodu przywrócić ręcznie taki plik SQL to można zwyczajnie zrobić to z konsoli mysql lub użyć dowolnego innego klienta (np. phpmyadmin czy cokolwiek). Generalnie jednak na co dzień używa się samych migracji.

4. Tak. To nie muszą jednak być losowe dane, równie dobrze mogą być w jakiś sposób zdefiniowane na sztywno jeśli jest taka potrzeba. Można też użyć factories, aby było czytelniej i wygodniej generować całe modele, są opisane w dokumentacji.

5. Przez seeder tak samo jak te generowane losowo, tylko że zamienić losowanie na przygotowane na sztywno dane, po prostu.

Co wybrać to raczej kwestia co się komu spodoba :) No i co chce się zrobić, bo żaden język nie jest idealny i czasem może lepiej czy gorzej pasować do danych specyficznych wymagań. Laravel jest fajny o tyle, że moim zdaniem szybko się w nim pisze, nie trzeba kombinować, bo po prostu wiele rzeczy na gotowo działa. Na minus to, że przez tę prostotę nie wymusza pewnych rzeczy, które spowodowałyby od razu powstanie lepszego kodu i użycia lepszych praktyk.

---

Widzę, że w zrozumieniu i poukładaniu bardzo pomaga mi opisanie problemu. Bo wtedy umiem zadać właściwe pytania, nie tylko na forum, ale i Googlowi.

Dzięki za pomoc i cierpliwość, bo dzięki Twoim odpowiedziom mam już drogowskazy i teraz tylko doczytać dokumentację i po robocie. W sumie wszystko wyjaśnione, więc można kodować dalej