Fwd: Re: Upgrading Django (to 1.7)

[Fred Stluka]

Bob,

Are you referring directly to the models by name in the data
migrations?  That could be the problem, because yes, the migration
would be using the latest models at the time that the migration is
executed, not the models as they stood at the time that the
migration was written.

There's a warning in a comment in the boilerplate code generated
for each data migration by the command:
% manage datamigration <app> <base_migration_name>

It says:

    def forwards(self, orm):
        "Write your forwards methods here."
        # Note: Don't use "from appname.models import ModelName".
        # Use orm.ModelName to refer to models in this application,
        # and orm['appname.ModelName'] for models in other applications.

and there is a dictionary of the models as they existed at that
time shown later in the same file.

If you always follow this advice and manipulate orm.ModelName
instead of appname.models.ModelName, it should solve exactly
the problem you are describing.

Hope this helps,
--Fred

---

Fred Stluka -- mailto:fr...@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

---

On 9/27/14 10:00 AM, bobhaugen wrote:

The problem we ran into was not with the order of migrations, it was that all of the migrations were running with the latest models.py code. The data migration was trying to move data from one model field to another model field, and the "from" field had been deleted from models.py. 

This was awhile ago, and my memory might be faulty. Do the latest migrations give you any way to deal with that situation? I mean, do they migrate the models in models.py in sync with the the database schema migrations?

I can see where a data migration might work in a schema migration sequence if you expressed it all in SQL, just dealing with the database alone, but we of course wrote in Python using the Django ORM.

On Friday, September 26, 2014 10:04:49 AM UTC-5, Fred Stluka wrote:

Bob,

You can control the order in which migrations run.

For South, see "depends_on" and "needed_by":
- http://south.readthedocs.org/en/latest/dependencies.html

For Django 1.7 migrations, see "dependencies":
- https://docs.djangoproject.com/en/dev/topics/migrations/#dependencies

--Fred

---

[bobhaugen]

Fred, thanks a jillion for the excellent advice! I obviously missed that bit in the data migration boilerplate.

On Saturday, September 27, 2014 9:29:10 AM UTC-5, Fred Stluka wrote:

Bob,

Are you referring directly to the models by name in the data
migrations?  That could be the problem, because yes, the migration
would be using the latest models at the time that the migration is
executed, not the models as they stood at the time that the
migration was written.

There's a warning in a comment in the boilerplate code generated
for each data migration by the command:
% manage datamigration <app> <base_migration_name>

It says:

    def forwards(self, orm):
        "Write your forwards methods here."
        # Note: Don't use "from appname.models import ModelName".
        # Use orm.ModelName to refer to models in this application,
        # and orm['appname.ModelName'] for models in other applications.

and there is a dictionary of the models as they existed at that
time shown later in the same file.

If you always follow this advice and manipulate orm.ModelName
instead of appname.models.ModelName, it should solve exactly
the problem you are describing.

Hope this helps,
--Fred

---

Fred Stluka -- mailt...@bristle.com -- http://bristle.com/~fred/

Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.

---

On 9/27/14 10:00 AM, bobhaugen wrote: