This society also has linters and such, so that DB migrations are safer
regarding deployment rollouts -
https://medium.com/3yourmind/keeping-django-database-migrations-backward-compatible-727820260dbb
On Saturday, June 29, 2019 at 10:36:11 AM UTC+2, Matthieu Rudelle wrote:
>
> Nice find, It's
Nice find, It's an interesting way to solve it. We might give it a try.
On Thursday, June 27, 2019 at 11:12:16 PM UTC+2, Pkl wrote:
>
> Just for reference, here is a package I crossed recently and which has an
> approach for that : https://github.com/3YOURMIND/django-deprecate-fields
>
> On
Just for reference, here is a package I crossed recently and which has an
approach for that : https://github.com/3YOURMIND/django-deprecate-fields
On Monday, June 24, 2019 at 3:15:04 PM UTC+2, Matthieu Rudelle wrote:
>
> Hi there,
>
> I can't find any previous ticket proposing a solution to
Does that sound like feature-request material? It seems to me django is the
good place to add this flexibility as it has exclusive access to the
underlying DB.
On Tue, Jun 25, 2019 at 9:08 AM Matthieu Rudelle
wrote:
> How does the "safe" field of migrations work with other migrations related
>>
>
> How does the "safe" field of migrations work with other migrations related
> commands, such as squashmigrations?
>
Squashmigrations typically targets and produces migrations that are old
enough to be assumed safe.
> You can check out our repository. We've been pretty happy with how
there are similar to `alter table drop column` issue: `alter table rename
column`, `drop table`, `rename table`. (honestly `alter table drop column`
and `drop table` a bit different wiith `alter table remane column` and
`rename table`)
Look like you general flow for migration:
1. change code
>
> If does not affect squashing. I think this is roughly reasonable, at least
> for my uses, although I haven't had any real world use for squash myself. I
> recently had to remake the migrations in my repo for $WORK project, and it
> made the most sense to keep them as the default safe after
On Mon, Jun 24, 2019, 21:29 Dan Davis wrote:
>
> Some questions:
>
>- How does the "safe" field of migrations work with other migrations
>related commands, such as squashmigrations? It seems to me that only
>migrations that share the same value of "safe" could be squashed.
>
> If
I'd agree that it is a definite use case. In the dev-ops world, it is
evidently called a "blue torquoise green deployment". It could be done as
long as the code is not adding a table/field/etc.
My discussion on django-users,
https://groups.google.com/forum/#!topic/django-users/QCmy9reH8cI,
I'm not sure about the solution you mentioned, but the problem you mention
is one that I definitely do deal with. At my work we have been happy with
using a "safe" migrate command that only runs migrations that are marked as
safe to run before the deployment happens, to address exactly this kind
Hi there,
I can't find any previous ticket proposing a solution to this problem so
here are my findings:
**Use case**:
When using continuous delivery several versions of the code can be running
in parallel on se same DB. Say for instance that release 2.42 is in
production, 2.43 is about to
11 matches
Mail list logo
