There seems to be different philosophies around data migrations. django does data migrations as part of migration via RunPython operations. Rails docs show how to interact with Models in a migration. A thoughtbot post suggests using rake scripts which aligns with our approach, where we use complementary scripts that we just go in and run on staging and production servers. I guess my question is what your take is on data migration or if youve limited it to only seeding ?

https://prisma.slack.com/archives/CBFFY3066/p1598002224009600?thread_ts=1598001013.007800&cid=CBFFY3066 You could 1. create a migration to add an optional slug field on your model 2. migrate your database 3. change and deploy your code so new created post get a slug 4. script a data migration: getting all records where slug is NULL and updating them to set their slug 5. Now all your records have a slug 6. You can then create a migration to make the slug field required

We are exploring ways to enable data migrations in the context of schema migrations, i..e backfill a missing value, etc. We realize there are actual use cases for more ellaborate data migrations to reconcile/clean up data, leverage 3rd party APIs, i.e. do geolocation lookups, etc. I think we eventually might support these cases, but I don’t know if this would be built into the schema migrations (Django) or rather as a separate affordance (Thoughtbot). We are not focusing on this problem space yet.

Thanks @Joël . What youre describing sounds like complementary scripts that we currently have in place to run manually after schema migration. Could automate it by keeping track of applied scripts - we dont want to reapply them. But now it starts to sound like migrations again. I suppose we can find an adhoc solution to attach some optional script to run next to the schema migrate.