On Tuesday 04 July 2017 20:39:37 tay...@cedar.com wrote:
> I am having some trouble figuring out the best way to remove model
> fields in Django. If I remove a field from a model and then run
> makemigrations, it creates a RemoveField operation in a migration.
> That is great, but if I decide to ru
Hi,
Well, seems that your deployment process needs fixing.
Simplest option is to stop serving site (put it to maintenance mode to
show for example static maintenance page), update codebase and run
migrations. Restart servers and put django serving back.
If you're looking zero downtime migrat
I am sorry everyone. I guess I am not very good at explaining the problem.
I will try explain it better. Please ignore everything I have written
before because it seems to be confusing.
I have perfectly working code in production. Later, I want to make a model
change to remove a field and updat
It seems to me more a organization/project management isssue that
something that should be handled by Django itself. Well, if I got the
problem correctly, that is.
It seems you can't remove the field from the Model class because that
would remove the column from the underline table itself as s
> On Jul 4, 2017, at 8:39 PM, tay...@cedar.com wrote:
>
> I am having some trouble figuring out the best way to remove model fields in
> Django. If I remove a field from a model and then run makemigrations, it
> creates a RemoveField operation in a migration. That is great, but if I
> decide t
Avraham,
Thanks for your answer again. When you say planning for the long term is
not ideal, what do you mean? I am interested in learning better processes.
I do currently work with 20 developers, if that is what you meant.
Your approach with a property was my first attempt. That didn't work
be
>From what you are describing it seems that you are planning for the long
term. which I don't believe is ideal
You may mark the whole model as not managed, but I don't think you can mark
just one field and unmanaged.
Another simple approach would be to transform the attribute to a property
and pri
Hi,
Sounds like your all developers do use same database if you have such a
problems.
It's usually good practice to have per developer development database.
That will allow individual developers to do changes to database and
migrate others as they please. Also it doesn't "matter" if one deve
Thanks for responding Avraham.
That would be a good option if I was developing by myself, but I am working
with a team of 20 developers. The process needs to be the same whether
there are deprecated fields or not. I can't realistically expect 20 people
to not apply one migration (or a few speci
you can remove the field and don't run migrations until you are ready to
actually remove the column, or you may run migrations fake and leave the
column there forever
https://docs.djangoproject.com/en/1.11/ref/django-admin/#cmdoption-migrate-fake
On Wed, Jul 5, 2017 at 6:39 AM, wrote:
> I am ha
10 matches
Mail list logo
