Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Paveł Tyślacki
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

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Dan Davis
> > 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

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Ryan Hiebert
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

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Dan Davis
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,

Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Ryan Hiebert
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

[Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

2019-06-24 Thread Matthieu Rudelle
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

Customizing the django user model ( ERROR :value does not refer to a Field )

2019-06-24 Thread Arash Ab
hi guys, i'm trying to customize the django user model but i get this error: : (admin.E033) The value of 'ordering[0]' refers to 'username', which is not an attribute of 'cms.PageUser'. : (admin.E108) The value of 'list_display[0]' refers to 'username', which is not a callable, an attribute

Re: j'ai une erreur de la fonction def __str__(self):

2019-06-24 Thread Aymeric Augustin
Bonjour Randa, Ce n'est pas la bonne liste de diffusion pour ce type de question. django-developers traite du développement de Django lui-même, pas de l'utilisation de Django. Je vous encourage à écrire a django-users ou à passer par un site tel que Stack Overflow. Par ailleurs, si vous