Home/ Questions/Q 9134717
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T08:42:46+00:00

I started using Laravel (I added RoR as a tag since I know that

  • 0

I started using Laravel (I added RoR as a tag since I know that the migrations are kind of similar between the two) just a few weeks ago and am still struggling somewhat getting used to working with migrations. I’ve tried to read some documentations and tutorials (both for Laravel and other frameworks who use them, like Rails) and they generally do a good job explaining how to use them, but I still fail to grasp how to effectively work with them. Some questions I have:

  1. If I create a table in a view and later on decide to add a few columns and maybe drop a few other, how do I do this? I understand that editing an existing migration is not the right way. Do I add a new migration which adds the new columns and drops the old ones? If so, is there a naming convention for them, when creating say a table called users, all the tutorials usually name the migration create_users, do I call this migration update_users? What if I wanted to make another update to users, then I would have two classes called Update_Users. Also, the problem I’m having with this approach is that I’m feeling like I don’t have a good overview over the database structure, a tables columns could be scattered over a dozen of migration files.

  2. If I want to populate my tables with test data, is it better to do that in separate migrations, like seeds in Laravel 4?

  3. Should I only have one table in each migration? As of know, in my create_users migration I create three tables; users, roles and role_user, is it better to put them in separate migrations?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1. Editing an existing migration is not the way to go. Otherwise the changes won’t be used when deploying to your production system (the migration numbers are stored in the database itself to avoid running them again). Add another migration to do the changes. There is no real naming convention for update/alter migrations in place. So name it the way you want. But a proper names pointing out why you did the migration may be helpful (e.g. AddCommentsToUsers).

    2. Rails has a seeding mechanism (see Screencast). You should use this. Data migrations have their drawbacks.

    3. I prefer one table per migration. If the first table creation runs through but the second doesn’t, you get into trouble later on when you try to rerun the migration (after having fixed any issue with).

    • 0