Notices by Paweł Świątkowski (katafrakt@genserver.social)

Embed this notice
Paweł Świątkowski (katafrakt@genserver.social)'s status on Tuesday, 10-Oct-2023 10:18:36 JST Paweł Świątkowski
in reply to
- clacke
- Pete Corey
@clacke @petecorey I don't have any principles formulated, but I usually just model data migrations as tasks (rake, mix, custom built triggered from admin panel...).

Even with regular migrations during the deploy you have a timeframe when the migration is already run, but you're still serving old code (with large codebases it's non-negligible amount of time). So I have a rule that migrations need to be compatible with old and new code anyway.

So you
1. Deploy schema migration
2. Run data migration
3. Deploy new code that relies on migrated data

Of course I can imagine situations where this does not cut it, but it works most of the time for me.

In conversation about a year ago from genserver.social permalink
Embed this notice
Paweł Świątkowski (katafrakt@genserver.social)'s status on Monday, 09-Oct-2023 03:39:32 JST Paweł Świątkowski
in reply to
- Pete Corey
@petecorey my go-to is to use migrations only for schema migrations and have separate machinery for data migrations. More on this here (although in Ruby context, but it applies to Ecto and others too): https://dev.to/katafrakt/data-migrations-in-regular-migrations-and-why-you-probably-should-not-do-that-2eem
In conversation about a year ago from genserver.social permalink
Attachments
1. Domain not in remote thumbnail source whitelist: res.cloudinary.com
  
  Data migrations in regular migrations and why you (probably) should not do that
  
  from @katafrakt_pl
  
  Every once in a while I read Lucian Ghinda's Short Ruby newsletter and I see a "take" there which...

Public

Notices by Paweł Świątkowski (katafrakt@genserver.social)

User actions

Following 0

Followers 0

Groups 0

Statistics

Feeds