webology, 21 days ago

@ehmatthes I would guess it's more tied to manage.py being run with a sub-command than any one action.

CodenameTim, 21 days ago

@ehmatthes I would have assumed migrate, but I'm guessing makemigrations because it needs to check the django_migrations table to determine which migrations have been applied.

ehmatthes, 21 days ago

@CodenameTim I had the same assumption, but the behavior was quite interesting when trying a few minimalist approaches.

With runsever active, saving settings.py after adding the DATABASES dict with SQLite as default resulted in an empty db.

Without runserver active, calling makemigrations results in a new db file.

If I call migrate without a db file present, a new db is created.

ehmatthes, 21 days ago

@CodenameTim Your mention of the django_migrations table led to a little more source code diving. I had always assumed there was a command somewhere in Django that created the db.sqlite3 file if needed.

TIL that creating a connection to SQLite creates the db file if it doesn't already exist.

ryanhiebert, 21 days ago

@CodenameTim @ehmatthes makemigrations doesn’t touch the database, it only looks at the models and the migrations to see if they match. showmigrations looks at the database.

ehmatthes, 21 days ago

@ryanhiebert @CodenameTim I believe makemigrations looks at the database to see which migrations have been applied:

https://github.com/django/django/blob/c187f5f9242b681abaa199173e02066997439425/django/core/management/commands/makemigrations.py#L137

More specifically, I think it's looking for inconsistencies in which migrations have been applied:

https://github.com/django/django/blob/c187f5f9242b681abaa199173e02066997439425/django/db/migrations/loader.py#L307

ryanhiebert, 21 days ago

@ehmatthes @CodenameTim that’s the way I read that code too, so I guess I’m wrong!