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 because Django still queries for the column by default,
unless every single queryset in the project we put
.only(<fields>) excluding the deprecated columns, which can
introduce other issues if we add new fields. I tried overriding
get_queryset to do that globally on the model, but Django doesn't
respect .only when doing inserts, only updates and retrieves.
We do have very good test coverage, so warnings would be a great
option if I could find a way to have Django not try to write or
query that field by default.
In regards to running migrations after deploying, that would be
very difficult. Some migrations need to be run before a code
release (adding fields), so people would have to be very careful
not to put an AddField and a RemoveField in the same code
release. Even if that was possible, we don't release manually (we
use continuous deployment), so we would have to write some kind
of migration reader that could determine whether to run a
migration before or after the release.
With your question about temporary, it may or may not be
temporary, it depends on the field. Certain fields can later be
removed safely, but there will be cases where we keep deprecated
fields forever for reporting reasons, etc.
On Wednesday, July 5, 2017 at 8:41:11 AM UTC-4, Avraham Serour
wrote:
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 print deprecation warnings or raise an
exception whenever someone tries to write to it (or read)
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
<red...@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, tay...@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/migration-operations/#writing-your-own
<https://docs.djangoproject.com/en/1.11/ref/migration-operations/#writing-your-own>
, 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?
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
https://docs.djangoproject.com/en/1.11/ref/django-admin/#cmdoption-migrate-fake
<https://docs.djangoproject.com/en/1.11/ref/django-admin/#cmdoption-migrate-fake>
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
<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%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/a52ae01a-1a7d-43ce-a94f-fb00c4e1b7d1%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout
<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...@googlegroups.com.
To post to this group, send email to
django...@googlegroups.com.
Visit this group at
https://groups.google.com/group/django-users
<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
<https://groups.google.com/d/msgid/django-users/e1f61e62-a6cc-44a4-ba35-7fa8b28c5549%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout
<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...@googlegroups.com.
To post to this group, send email to
django...@googlegroups.com.
Visit this group at
https://groups.google.com/group/django-users
<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
<https://groups.google.com/d/msgid/django-users/d4ba64c5-0dac-bcb4-520f-78835d049ad4%40gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit
https://groups.google.com/d/optout
<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...@googlegroups.com <javascript:>.
To post to this group, send email to django...@googlegroups.com
<javascript:>.
Visit this group at https://groups.google.com/group/django-users
<https://groups.google.com/group/django-users>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/f8891294-3be5-41d0-a6a7-9740d7b8b3bb%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/f8891294-3be5-41d0-a6a7-9740d7b8b3bb%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
