Yes, I see now why it's not possible to simply do a rename. Ok, I will go with the first option. Thank you very much for such a detailed answer!
On Tue, Oct 27, 2015 at 8:44 PM Jeremy Evans <[email protected]> wrote: > On Tuesday, October 27, 2015 at 11:54:40 AM UTC-7, Janko Marohnić wrote: >> >> Hey Jeremy, >> >> I'm trying to do a column rename in production, and I want to have zero >> downtime, so I want to somehow write to the original column, and then when >> I run the migration I want to start writing to the renamed column. However, >> if I run the migration, the schema won't be updated. Is it somehow possible >> to refresh the schema inside the method? Or just `Sequel::Model.column` >> would also be great. I thought it would be good to do something like this: >> >> class Company >> def similar_domains >> refresh_schema >> column = columns.grep(/similar_domains/) >> send(column) >> end >> >> def similar_domains=(value) >> refresh_schema >> column = columns.grep(/similar_domains/) >> send("#{column}=", value) >> end >> end >> >> I'm renaming `similar_domains_array` to `similar_domains` (the rest of >> the production code is currently referencing `smilar_domains`, which I'm >> currently delegating to `similar_domain_array`). >> > > You should do zero downtime migrations in the following manner: > > 1) Modify the code so that it will work both with the old schema and the > new schema > 2) Modify the schema (run the migration) > 3) Remove support in the code for running with the old schema. > > This should not require refreshing the schema inside a running > application. I think that's probably impossible to do without a race > condition. > > For renaming of a column, on PostgreSQL, one way to do a zero downtime > rename is: > > 1) Add a new similar_domains column via a migration > 2) Have your application write changes to both the similar_domains and > similar_domains_array column > 3) Run a migration that syncs similar_domains_array to similar_domains in > the cases where they differ > 4) Modify your code to only write to similar_domains > 5) Remove similar domains_array > > Alternatively, you may be able to use a view instead of a table: > > 1) Add a view for the table that aliases similar_domains array to > similar_domains. > 2) Have your application use the view instead of the table > 3) Run a migration that renames the similar_domains_array to > similar_domains in the table, and updates the view to match. > > I'm not sure if you can add a rule that will allow for a zero downtime > migration; I don't have much experience with rules. > > Thanks, > Jeremy > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sequel-talk" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sequel-talk/afEQLvX42tQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sequel-talk. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
