skip to Main Content

Hello everyone

I’m going to try to explain my problem as clear as possible, feel free to ask me more precision if you didn’t understand what I meant and forgive my mistakes, English is not my mother tongue.


My goal

I want to start using migrations again because I need to create a new table, after a year where developers of my company bypassed them by creating/deleting/updating tables directly from phpmyadmin.


The things you have to know

The last migration was a year ago, but many tables have been created without migrations since that time.


Why I need your help

I’d like to know what is the best way to start using again migration without losing data or tables, because I’m working on an environment production.
What is the best way to do that ? Keeping the migrations that already exists and just ignoring the tables that have been created ? Deleting all migration files and deleting all the row in the migration table ?

If I delete all the migration files and truncate the migration table, will a php artisan migratewill have any impact on the existing schema ?

What is the best practice ? Should I recreate all the migrations of all the tables of my schema ? Or should I create only one migration with the new table I want to create ?

3

Answers


  1. You could start from scratch by deleting all migrations and truncating the migrations table.

    Then take a look at this post to recreate all the migrations for your current database schema.

    Login or Signup to reply.
  2. Laravel keeps track of the migrations using a dedicated table that records when they were applied. When any one migration gets run, it inserts a new record in the table, and if you roll back a migration the corresponding record is deleted. You can therefore prevent undesired migrations from being run by adding them to this table.

    My advice would be as follows:

    • Create the missing migrations
    • Run them on your local copy to get the database in the required state there
    • Export the migrations table
    • Import it to the production database
    • If you have any additional migrations you want to run after the ones you ran locally, run them in production

    I’d definitely be careful to have a dry run beforehand though – perhaps after exporting the migrations, import the production database to your local copy, then import the migrations, and check it there.

    I’d also be inclined to take steps to stop people applying changes to the production database directly – it’s a very dangerous step that avoids accountability and makes it hard to test your application locally. Perhaps lock down PHPMyAdmin.

    Login or Signup to reply.
  3. Mostly in these cases I try to sync migrations with my table so that I don’t lose the current data which is on the database and I know that my migrations are updated .
    So I from the first table whatever you have added in your table manually, you have to add that to your migration too .
    In this case in future if you need to create a database truncate or anything else you know that your migrations are already up to date .
    To be honest the best practice is to make the changes in your migration not in the database so you have not done the best practice so . this is the best practice that even can be done in your case so you make a migration to your project like this :

    php artisan make:migration added_photo_to_user_table --table=users
    

    and then in your migration :

     public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->text('photo')->nullable;
    
        });
    }
    

    then u have to run the command

    php artisan migrate
    

    but in your case because you added the fields to the database you don’t need to run the last command you just have to make migrations so in future if you want to make update to the database you do it as the best practice and you don’t encounter any data lost .

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search