[HN Gopher] Zero-downtime Django migrations
       ___________________________________________________________________
        
       Zero-downtime Django migrations
        
       Author : cryvate1284
       Score  : 49 points
       Date   : 2022-05-10 19:55 UTC (4 days ago)
        
 (HTM) web link (cheigh.me)
 (TXT) w3m dump (cheigh.me)
        
       | latch wrote:
       | I don't know Django and what Django-specific problems/solutions
       | are available, but AFAIK the only scalable (and largely language
       | agnostic (1)) solution is to break these down and deploy
       | incremental versions of the app.
       | 
       | For example, they give an example where widget_description is
       | being added which must be not null. But this should be two
       | migrations: 1) adding the column, 2) making it not null. And
       | because these are now split, they can make incremental changes to
       | the app to accommodate these migrations - the first version
       | working when widget_description is nullable and the second, after
       | the data is fully migrated, when it isn't.
       | 
       | (1) If you're using any `select *`, it's important that your ORM
       | ignores unknown columns (e.g. newly added). I've inherited
       | systems that used libraries that behaved like this, and it's
       | awful.
        
         | singron wrote:
         | Rails used to cache the list of columns after the first query
         | and then expect all of those columns on subsequent queries. It
         | made it so that if you removed an unused column, all your
         | queries would fail until you restarted your rails processes.
        
           | byroot wrote:
           | That's what `ignored_columns` is for: https://api.rubyonrails
           | .org/classes/ActiveRecord/ModelSchema...
        
           | nijave wrote:
           | Semi related https://github.com/ankane/strong_migrations
        
         | bpicolo wrote:
         | Postgres has been able to safely add a not-null column with a
         | default since version 11 (2018).
         | 
         | https://www.postgresql.org/about/news/postgresql-11-released...
        
           | latch wrote:
           | Some migrations are non-trivial and might take hours or days
           | (e.g. they could involve hitting external services, or might
           | require manual work). Sure you can default these, but `null`
           | is probably semantically correct in most cases
        
           | true_religion wrote:
           | Isn't that painfully slow in production? Or is that a mistake
           | on my part?
        
             | scrollaway wrote:
             | You might be thinking of older postgres. See this SO:
             | https://dba.stackexchange.com/a/211222
        
         | code_biologist wrote:
         | One of my favorite explanations of how to do incremental
         | versions: https://stripe.com/blog/online-migrations
        
       ___________________________________________________________________
       (page generated 2022-05-14 23:02 UTC)