Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Patrick Koch
40,496 PointsExplain Migrations
Hello Pros,
I dont really understand the sense of Migration:
Laravel Migrations are like version control for your database, allowing a team to easily modify and share the application's database schema. Migrations are typically paired with Laravel's schema builder to easily build your application's database schema.
So what I understood in the video from Hampton we can edit/create/undo tables with a phpartisan migrate command seems pretty needy but, can somebody pls show me another example for use, then I propably understand it.
Its really hard to explain, So if i would work with laravel and wanted to create a table in my database, I would just run php artisan make:migration create_users_table this command creates a file in database/migration/ that I can edit and run php artisan migration agian to update the table
to create a table, but helps me that to work in team?
2 Answers
Kevin Korte
28,149 PointsYou got it. You can pretty much do whatever you need to do to a table(s) in a migration file. Each migration file is like a "step" or "bookmark", and you can roll forward or back through the steps.
Basically, when you run a migration file, your code in your migration file is converted to a SQL statement, and that SQL statement is ran on the database. The cool part about this is it will take into account which type of database you are using, and run the appropriate syntax for that.
The really cool part is when you have more than one dev, if you make a change to the database, and check the new files into version control (git), and all your other dev friend has to do is pull the new changes from version control, and run the migration, and his local dev database will reflect the exact changes yours has.
That's why they say it's like version control for databases. Hope that helps.
Patrick Koch
40,496 PointsAh ok I see, and I wondered why the migration files have always the date in front of the name, makes sense now. Thanks a lot Kevin, I slowly see the advantages of this. So you don't need to do the mysql export and import. I never worked with different database types, but it that makes sense
g patrick
Kevin Korte
28,149 PointsThe date does two things. One it is to keep the migration files in order, two is it almost insures unique file names. It would be possible two devs might make the same migration file name, and the date string gives it uniqueness, it would be very rare that two devs would make the same migration file at the exact same time.
However, migrations only carry the schema with them, not the data, so if you wanted someone to have populated data, you'd need to export the database file with the migrations.