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.
I hope that if you have tests it will be enough to remove all use of the deprecated field
Is that temporary? That would influence the approach
From what I understood from your original post this is just a matter of deploying the new app version that removes a field, so you would just need to run migrations after deploying
On Wed, Jul 5, 2017 at 3:18 PM, Jani Tiainen <redetin@gmail.com> wrote:
--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 developer breaks their database for example by accidentally running migrations that are not in the repo yet.
Of course, it requires that you have either database creation script, or like we do, we clone our staging database for development basis.
On 05.07.2017 15:09, taylor@cedar.com wrote:
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 specific ones). There may be other migrations after the deprecation that need to be applied, so it's very difficult to apply certain ones and ignore others. It would be similarly difficult to get everyone to apply one of the migrations with --fake, but do a different process with every other migration. Also, --fake applies to the entire migration (not just specific operations), so people would be forced to make separate migrations for other model changes and hopefully remember not to run --fake on those.
My current best attempt was to create a custom DB migration operation https://docs.djangoproject.com/en/1.11/ref/ , that removes the field in state_forwards, but doesn't do anything to the db in database_forwards. That works, but the person that deprecates the field need to remember to change the RemoveField operation into the custom DeprecateField operation. It would be great if makemigrations created the correct operations automatically. Is there a way to do that?migration-operations/#writing- your-own
On Wednesday, July 5, 2017 at 7:27:22 AM UTC-4, Avraham Serour wrote: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
On Wed, Jul 5, 2017 at 6:39 AM, <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 run the migration before releasing the new code, the existing code will break (for a short time between running the migration and releasing the new code) because the old code is still querying for the removed column (Django queries for all columns by default). I could run the migration after the release, but that won't work if I also have an AddField operation because the new code needs the new column, so it needs to be run before. I am wondering if anyone has solved this issue?--
My best solution (I don't think Django supports this) would be to have a special type of field called a DeprecatedField. It would delete the field from Django's perspective, but keep the column in the DB. Django would no longer query for the column, but the column would still be in the DB. On the next release, I could remove the column completely (with a RemoveField operation) and the existing code would not error because it has no knowledge of the column.
I noticed Django has an idea of a private field, which is on a model but not in the DB. Is there a way to create a field that is in the DB, but Django model doesn't query for it or allow it to be used in creates and updates? Very similar to the managed=False on the Model, but on the Field level. If anyone has other approaches to the problem, I would be very excited to find alternative methods.
Thanks,Taylor
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a52ae01a-1a7d .-43ce-a94f-fb00c4e1b7d1%40goog legroups.com
For more options, visit https://groups.google.com/d/optout .
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com .
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e1f61e62- .a6cc-44a4-ba35-7fa8b28c5549% 40googlegroups.com
For more options, visit https://groups.google.com/d/optout .
-- Jani Tiainen
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com .
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users .
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d4ba64c5- .0dac-bcb4-520f-78835d049ad4% 40gmail.com
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tJ9_18-3SWVx13YvXhsiXG3JAjtas-sKeLWb8G41DZEwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment