How to avoid database migration hell
summary
Argues migrations manage schema only and seeds manage data, with concrete commands like artisan make:migration and using Faker + factories for realistic test/demo rows; compares truncate vs append seeding strategies, shows disabling foreign keys for truncation and using in‑memory SQLite for fast tests; describes packaging the database dir as a composer package so web app runs migrations in production while the API uses it as a dev dependency; reports hundreds of messy migrations forced a rewrite and the composer approach works.
AI-written summary · about
chapters (22)
- 0:00Intro
- 1:19WHAT IS A DATABASE MIGRATION?
- 1:38WHY USE DATABASE MIGRATIONS?
- 6:14HOW DO I MAKE A MIGRATION?
- 7:59WHAT DOES A MIGRATION LOOK LIKE?
- 10:14WHAT IS A DATABASE SEED?
- 10:37WHY USE DATABASE SEEDS?
- 16:03WHAT DOES A SEED LOOK LIKE?
- 17:46MODEL FACTORIES IN LARAVEL
- 19:18CATEGORISING YOUR SEEDS
- 21:10DATABASE SEED STRATEGIES
- 24:27WAIT, WHY NOT USE MIGRATIONS?
- 25:57TRUNCATION STRATEGY SEEDS
- 28:27APPEND STRATEGY SEEDS
- 30:20CODE DEFENSIVELY
- 36:27COMPOSER TO THE RESCUE
- 36:50DATABASE PACKAGES
- 37:30STRUCTURING YOUR COMPOSER PACKAGE
- 38:52SETTING UP THE COMPOSER PACKAGE
- 40:04LARAVEL. CONFIGURATION
- 40:50INSTALLING THE COMPOSER PACKAGE
- 42:05SUMMARY
related talks
36mUsing migrations and fixtures
26mDjango migrations, friend or foe? Optimize them for testing
35mDatabase migrations without downtime
31mHelp! My Database Is The Bottleneck
37mDatabase Schema Migrations with Zero Downtime
45mrails db:migrate:even_safer
36mUp And Down Again: A Migration's Tale
33mDatabase Schema Migrations with Zero Downtime