Details
- Reviewers
machniak - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rK kolab
- Lint
Lint Skipped - Unit
No Test Coverage - Build Status
Buildable 52414 Build 18584: arc lint + arc unit
Event Timeline
move the migration to the environment specific overlay
This way the base migrations can care about setting up the db table,
and we can keep data changes (which only make sense for pre-existing systems) separate.
We should probably contemplate a standard mechanism for cases like this, so we don't copy paste these definitions around.
We call the seeder after migration, so the seeder will fail because the record already exists.
BTW, none of the other registered passport clients are added via the migration. Maybe they should too. However, as all of them depend on existing-in-config client secrets and Ids, I'm still not sure migration is the correct place. Maybe we should have something like a "global seeder".
We are not creating the other seeders in a migration because they exist for all other environments, either because they were manually created, or because they deployment is more recent than the seeder.
I think the fundamental problem is that we have a seeder, which only makes sense for new deployments, and a migration which mostly only makes sense for existing deployments (but happens to also define the database schema).
I think ideally we would separate these responsibilities:
- Database schema
- Database schema migrations
- Database seeder
- Database seed migrations
And we would only ever run either the initial thing (Database schema or seeder), OR the migration, and we avoid duplications as much as we can.
Arguably the database schema is not really required given the migrations gets the job done (someday we may want to squash our migrations though), so perhaps we ignore that for now.
The seeder we have, but running seed migrations + seeder doesn't really make sense, and running seed migrations can be problematic because of db constraints etc. (we cleaned up a whole bunch of data related migrations a while back).
So perhaps we come up with some standard hook that we can call in the migrations, which only runs if we actually have to execute the seed migration, and doesn't duplicate the code by calling the code in the seeder (we just have to split things out into static functions as required)?
I suppose doing this during a migration is a bad idea because this also depends on the configuration to be available.