Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
✨ Migration runner - first iteration #7501
This is a pure implementation of the new migration runner.
Each type (
By storing each script into the database, we can easily check the health of the database.
We still need to ensure that a migration script itself can run twice if it get's executed twice.
If you remove your sqlite db and run:
You can also run it twice, to see that it will skip the
This won't work with Ghost yet!Therefor we have the next PR #7502.
To clarify here, as I understand:
Hmm i didn't really really start with seeds yet, but here is what i thought how it will work:
Hmmm I think it's ok to extend the migration runner in the next iteration for seeds and migrations.
Facts for next iterations:
Ok - one thing that's worth flagging up here, I think:
The biggest, longest-running pain point that seriously impacted our ability to ship, was being able to safely migrate permissions fixtures. Whilst the code we have for doing that is undeniably large and complex, it did create a very easy way for us to add to the permissions fixtures, which has allowed us to ship more in the last few months where previously we were stuck.
I think it's important to consider that initialising fixtures, and changing or adding to them are two separate things which we will also definitely have use cases for, and that doing it needs to be super simple. Also perhaps worth thinking about the fact that tests also need fixtures (Sometimes we want to mirror the defaults, sometimes you want custom fixtures).
There is a subtle difference here in terminology that I think is making me feel uncomfortable. The concept of "seeds" and "seeding" have been, everywhere I've encountered them (rails, bookshelf), a 1-time thing. Rather than something that can easily be adapted or migrated.
Seeds are a one time thing. When your database has reached the "was seeded" state, you can not seed it again. You can try, but it will skip, because each script which was running, is remembered in the migrations collection.
Does this confuses you?This structure was created in my head because seeds are basically just a migration script. And it makes things easier to read when having not everything in one big file like
Initialising fixtures is seeding the database. Changing/adding them is a migration script.
I am a bit confused about your comment, maybe we can talk in DM shortly, not sure what you are going to point out here