On 20/04/2018, at 16:07 , Guillermo Iguaran wrote:
>
> > +1 to popularising the idea of post-deployment migrations though. We do
> > this at our company (using a small patch to the migration code - I’ll post
> > it if anyone wants it) and it in practice allows us to cover a lot of the
> > maj
Hey Guillermo, please do share your patch I'm interested :)We are also
patching migrations :)
I was exploring adding sprinkles of "no-dowtime" migration to Rails in the
last few months, but I'm hitting the dead-end (for similar reasons that
Will and Xavier mentioned)
On Friday, April 20,
> +1 to popularising the idea of post-deployment migrations though. We do
this at our company (using a small patch to the migration code - I’ll post
it if anyone wants it) and it in practice allows us to cover a lot of the
major use cases such as adding a new column and starting to populate it in
Excellent email Will, agree with all your points.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post t
Yeah, I agree that this is best attacked by documentation rather than coding it
into Rails or using strong_migrations. Unfortunately even for that simple
example, the best way to add columns is actually completely database-specific
and version-specific.
For example, the below advice is the rig
Yes, definitely planning will always be a part of it. There are some things
that we can do to help, though. For example, can `add_column` automatically
avoid locking the table by adding a column, then adding a default value?
Maybe that shouldn't be the default, so instead maybe add a new method
https://github.com/ankane/strong_migrations
On Wednesday, April 18, 2018 at 11:58:45 PM UTC-3, Dillon Welch wrote:
>
> Perhaps Rails could throw a warning of some sort for non-safe migrations?
>
> On Wed, Apr 18, 2018 at 5:48 PM, Xavier Noria > wrote:
> > Migrations without downtime are mostly
Perhaps Rails could throw a warning of some sort for non-safe migrations?
On Wed, Apr 18, 2018 at 5:48 PM, Xavier Noria wrote:
> Migrations without downtime are mostly a logical problem. You need to write
> them in a way that allows schema or data changes and two versions of the
> code coexisting
Migrations without downtime are mostly a logical problem. You need to write
them in a way that allows schema or data changes and two versions of the
code coexisting. Sometimes that means planning a schema change in a
coordinated way that perhaps requires a couple or three deploys.
At the framework
A RailsConf talk by Kir Shatov (blog post -
http://kirshatrov.com/2018/04/01/async-migrations/) got me thinking about
database migrations. Shopify has written a custom method for running
migrations asynchronously and separate from deploys. They try to make all
migrations backward compatible so
10 matches
Mail list logo
