lsvagusa's avatar

Repopulating UI data tables w/ migrations

Hi everybody, a question regarding reoccurring need for migrations.

The team I am part of is the RND phase, although we do keep a small production server up so we can onboard family and friends. We store some crucial data that populates our UI in the database and the data is pretty hefty (quite a few columns from multiple tables). This data really isn't something to throw into a config file or similar.

We can't afford to spend time on an admin panel, so whenever this data from the db needs changes I do the following via migrations:

  • truncate the tables (the FK constraints set up don't let me use DML and I don't want to alter them)
  • refill the tables

This works well enough (I do also like being able to track the changes made to the data through Git later), but is cumbersome. What I mean by cumbersome:

  • take a look at the last version of the migration that filled up a specific table
  • generate a new one
  • copy paste the old one
  • make changes to it
  • run the migration

Until we get a proper admin panel going I'd love to hear opinions on how you've handled situations like this.

0 likes
2 replies
Snapey's avatar

change the original migration and run artisan migrate:fresh each time

1 like
Jsanwo64's avatar

Stop using migrations for recurring UI data inserts, switch to Laravel Seeders with upsert instead.

Migrations are meant for schema changes, which is why your current workflow feels cumbersome (copy/paste, truncation, FK conflicts). Laravel already provides a built-in solution for data that needs to be repopulated or updated over time: Database Seeders.

Try to streamline this way;

  1. Move UI data into a seeder (e.g., UiDataSeeder)

Instead of truncating and re-inserting, use upsert so the script is safe to re-run and respects foreign key constraints:

DB::table('ui_items')->upsert([
    ['id' => 1, 'name' => 'Option A', 'value' => 'foo'],
    ['id' => 2, 'name' => 'Option B', 'value' => 'bar'],
], ['id'], ['name', 'value']);

  1. Edit data in one place (array or JSON file) You just update the dataset instead of creating a new migration each time.

  2. Apply the changes with:

php artisan db:seed --class=UiDataSeeder

This keeps everything version-controlled in Git, avoids foreign key headaches.

1 like

Please or to participate in this conversation.