phpmyadmin Question posted in
The official documentation can be found here.

Catch Migrations Up To Live Database – Phpmyadmin

Kind of a backstory, I inherited a Laravel project that initially used migrations and Eloquent to handle schema changes on it’s database, but through the course of development the original developer decided it would be better to just ditch to migration workflow and directly make the changes to the schema via sql/ phpmyadmin and in code using the DB class.

As for the question, what would the best way be to return back to using migrations and Eloquent after all of these years of deviation?

I could:

  • Clear the original migrations and start over.
  • Try to update the models and create the new migrations while hoping it all works fine.

Are there any other, better methods for doing this?

Tags:

2

Answers


  1. 0

    I would suggest this:

    https://laravel.com/docs/8.x/migrations#squashing-migrations

    However, since your DB is not in sync with your migration files, you should export the schema manually, and ditch the anti-pattern by creating migration for any future change.

    As per documentation, after executing the schema file’s statements, Laravel will execute any remaining migrations that were not part of the schema dump, so this would solve the issue you have.

    Login or Signup to reply.
  2. 0

    For further quality development, and for running CI/CD on daily basis you will need up to date database structure.

    Next step is fully based on the size of your project.

    If you have time to write missing migrations and project not so big:

    • Create a fresh copy of a project
    • Migrate all exists migrations
    • Compare all tables one-by-one and create a new migration per each
    • When you done, refresh from scratch and compare once again with production
    • If structure equals – mark them as migrated on production
    • Continue with normal migrations from this point

    If you don’t have time:

    • Create basic dump of the current DB
    • Remove all sensitive data
    • Use it in local, test, stage, CI/CD environments on DB start up
    • Continue with normal migrations from this point

    Second case is also good, as it provides basic Seed data for project setup for newcomers and other set ups.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search