Develop Reference

Reordering Initial Migration operations

Every time I try to migrate my initial migration, right after makemigrations, I get errors like :
django.db.migrations.exceptions.InvalidBasesError: Cannot resolve bases for [<ModelState: 'Project.Class'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
The reason I think this happens is because the order of model operations in the 0001_initial.py migration is incorrect. Operations with classes which inherit from others are added before their parents'. After I reorder the operations, it works: Process finished with exit code 0. Cool! But how do I make makemigrations work without doing this every time?
Thanks!
ps. I tried reordering the import order of my models in the model's __init__.py but it didn't work.

If you have several apps in your Django project and in models of one app models of another app are referenced - this may result in such conflict.
It is recommended to create migrations for each app separately and reference another app migration as a dependency in referencing migration file.
python manage.py makemigrations app-one
python manage.py makemigrations app-two
# example of referencing dependent migration,
# so app-two 0001 migrations runs after app-one 0001 migration
# app-two/migrations/0001-initial.py
dependencies = [("app-one", "0001-init.py")]

Should I avoid using models in django migrations?

I am working on an existing Django project that contains migration code like:
someFluffyModel.objects.all().delete()
or
someModel = SomeModel(....)
someModel.save()
Now wherever there is such code and newer migrations change the schema that reflect the current version of the model, there is an issue in applying migrations from scratch.
As I understand the reason is that the model used in the migration doesn't reflect the model used in the migration at that point in time. As I have found fixtures can help in loading data but how about deletion?
Is the preferred way to manually delete data from the database?

Sorry forgot to answer my own old question it's been years now but just in case anybody is curious in your migrations you should always be using historical models. The reason is that you get the model at a point in time(reconstructed incrementally base on schema migrations).
def forwards_func(apps, schema_editor):
# We get the model from the versioned app registry;
# if we directly import it, it'll be the wrong version
Country = apps.get_model("myapp", "Country")
This way if you try to re-run your migrations at some point in the future with model schema x'' old migrations will be run using x' and x depending on their dependencies.
Avoid importing models to your migrations directly at any cost.
It is always important to be able to rer-run you migrations since that allows you to migrate forwards backwards between your environments roll back faulty deployments and above all run your tests. If you are doing it wrong your tests will fail at some point when you'll get to schema x' and you'll have to follow the correct approach mentioned above to fix them.
Thanks to #Daniel Roseman for giving me some pointers that day.

Risk to overwrite tables via Django Models migrations?

I'm currently trying to update my Django models to incorporate some new functionality but after runnning "makemigrations", the console output makes me worried I'm going to overwrite other tables in the database.
Essentially, in my models.py, I have 8 models. One is entirely new, one is merely modified. I want to migrate these changes to the database so I run "makemigrations". A migration's file is created (I note there are no others whatsoever - presumably the colleague who created these originally has deleted them for whatever reason). The console output is:
- Create model ModelNew
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelDontTouch
- Create model ModelUpdated
Why does it say create model? Is it because, as far as Django knows, this is the first migration ever performed? Or does it plan on overwriting all those other tables (which would kill our app completely and result in a very terrible day)?
I also notice some models have specified
db_table = 'some_table'
db_tablespace = 'sometable'
others, just,
db_tablespace = 'sometable'
others, nothing at all. Anyone have any thoughts on this?

Django doesn't interrogate the database itself when making migrations; it builds up a graph based on previous migrations and the current state of the models. So if there are no previous migrations Django will create them from scratch. This won't overwrite your tables, but it won't actually work either, as it will attempt to create them and the database will refuse.
One option would be to temporarily revert your changes and run makemigrations again to get back to the right starting point, then run that migration with --fake-initial to mark it as applied without actually doing it, then reapply your changes and run makemigrations again.

Edit database outside Django ORM

If one is using Django, what happens with changes made directly to the database (in my case postgres) through either pgadmin or psql?
How are such changes handled by migrations? Do they take precedence over what the ORM thinks the state of affairs is, or does Django override them and impose it's own sense of change history?
Finally, how are any of these issues effected, or avoided, by git, if at all?
Thanks.

You can exclude a model completely from the django migrations, and then you are responsible to adjust the schema to the django code (or the django code to the existing schema):
class SomeModel(models.Model):
class Meta:
managed = False
db_table = "some_table_name"
name = models.Fields....
Note that you can't have it both ways, so migrations are preferred when possible. You can always define a custom SQL migration, that will save the need for external changes. However, sometimes you do need to handle the schema elsewhere instead of migrations, and then use managed=False

The migrations system does not look at your current schema at all. It builds up its picture from the graph of previous migrations and the current state of models.py. That means that if you make changes to the schema from outside this system, it will be out of sync; if you then make the equivalent change in models.py and create migrations, when you run them you will probably get an error.
For that reason, you should avoid doing this. If it's done already, you could apply the conflicting migration in fake mode, which simply marks it as done without actually running the code against the database. But it's simpler to do everything via migrations in the first place.
git has no impact on this at all, other than to reiterate that migrations are code, and should be added to your git repo.

What migration order does South follow across different apps?

I've recently begun using South for migrations in my Django project. All was going well until recently when I ran into a peculiar issue.
I have two apps in my project, say, App-A and App-B. A model in App-A has a foreign key to a model in App-B. When I've been trying to build my system, I ran syndb which created all the auth_ and the south_ tables. Then I ran migrate which threw up errors. When it tried creating the model from App-A, which referenced a model from App-B, the model App-B wasn't migrated/created as yet and therefore the error.
In order to resolve this, I had to manually migrate App-B first and then App-A. Am i doing something wrong here? How is South supposed to know the migration order across apps?
Thanks.

This explained it https://south.readthedocs.io/en/latest/dependencies.html.
Migrations for apps are nice ‘n all, but when you start writing a
large project, with a lot of apps, you realise you have foreign key
relationships between apps and working out what order migrations would
need to be applied in for each app is just painful.
Luckily, we also had this problem, so South has a dependency system.
Inside a migration, you can declare that it depends on having another
app having run a certain migration first; for example, if my app
“forum” depends on the “accounts” app having created its user profile
table, we can do:
# forum/migrations/0002_post.py class Migration:
depends_on = (
("accounts", "0003_add_user_profile"),
)
def forwards(self):
Then, if you try and migrate to or beyond 0002_post in the forum app, it will first make sure accounts is migrated at least
up to 0003_add_user_profile, and if not will migrate it for you.
Dependencies also work in reverse; South knows not to undo that
0003_add_user_profile migration until it has undone the 0002_post
migration.
You can have multiple dependencies, and all sorts of wacky structures;
there are, however, two rules:
No circular dependencies (two or more migrations depending on each
other) No upwards dependencies in the same app (so you can’t make
0002_post in the forum app depend on 0003_room in the same app, either
directly or through a dependency chain.

South migrates apps in the order they appear in the INSTALLED_APPS tuple in settings.py. So just make sure App-B comes before App-A in your settings.py, and it should work :)