A Web Developer’s Blog
The Laravel database validation rules are more powerful and flexible than I realised at first.
Looking at the Available Validation Rules we can see that Exists and Unique both have the suffix (Database)
This is because the both implement the DatabaseRule trait which offers more power than might be expected.
Laravel has some really good features for setting database connections - but oddly this isn’t spelled out in the documentation.
Databases (especially in Docker containers) often come by default with a single, powerful, user account.
As a result all too often people run Laravel without considering the principle of least privilege.
By following a few simple steps we can enhance security.
Laravel’s database migrations is a great system and makes it easy for the development team to stay in sync with schema changes as well as ensuring tests can run against a defined database state.
It also makes great use of transactions to efficiently roll back changes after each test
But what if you have some large tables of fairly static data that you don’t want to reload on every test run …
Something didn’t quite click with me about Laravel Eloquent Models.
There is nothing in the Model that defines the fields.
The Model defines which database table the data is stored in.
Whatever fields are in the table will be loaded to the Model.
I wanted to better understand what is happening when I run Laravel tests that hit the database.
TLDR: Database migrations are run on every test run, optionally with seed data.
Each test case runs in a transaction.
(This is written based on Laravel 9)