0

This question asks where the Django installation is.

This question is about the table django_migrations.

I've looked under the path from the command django in the interactive console, where I find a subdirectory db, along with middleware, etc.

But I've no idea where this table django_migrations (i.e. the data in it) is in fact kept.

I want to know firstly because I want to know what happens if this data is lost. I'm just learning Django and I don't quite understand how much of a problem this would be.

The path to the Django location is under a directory in my home folder where I keep my Python virtual environments, the name of which begins with a ".". I tend to exclude such directories from my backup plans...

Having just deleted db.sqlite3 in my project I see that it gets regenerated when you do migrate, together with a list of (in my present case) some 15 migration operations. I'm quite mystified by some of these: the first 10 or so seem to have occurred before I started doing anything to my models.py file. Are they documented or explained somewhere?

mike rodent
  • 14,126
  • 11
  • 103
  • 157
  • What do you mean "Django's own database"? What database have you *connected* it to? Which are you using https://docs.djangoproject.com/en/3.0/ref/databases/? – jonrsharpe Apr 13 '20 at 13:31
  • The table is in your database. It's not in some Django folder. The Django folder holds the *migration* which specifies how that table will be set up. It is *actually* set up in your database, the details of which you configure in `settings.py`. – deceze Apr 13 '20 at 13:31
  • @jonrsharpe Sorry, I am a beginner. My project is using the db.sqlite3 database in the project directory, which I believe is the default user database. But I can delete that and it gets regenerated from commands kept ... where? – mike rodent Apr 13 '20 at 13:34
  • @deceze Thanks. In my settings.py I see `BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))` and then later `DATABASES = ... 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),` ... but as I say it is perfectly feasible to delete db.sqlite3 and it then gets regenerated with the `migrate` command, using instructions from ... where? – mike rodent Apr 13 '20 at 13:38
  • Where'd you look? It'll be a combination of the selected backend (https://github.com/django/django/tree/master/django/db/backends) and the migrations. – jonrsharpe Apr 13 '20 at 13:40
  • @jonrsharpe "selected backend". Do you mean sqlite3? I am getting the impression that everything `migrate` does involves information contained within your own project directory (including inside models.py)... is this right? – mike rodent Apr 13 '20 at 13:46
  • Yes, if that's the one you're using. Django supports several databases out of the box. No, as you've been told some of the migrations come from other apps you're using. – jonrsharpe Apr 13 '20 at 13:47
  • OK the fog is clearing. "Other apps". So these must be apps under Django's installation directory, I suppose... ? – mike rodent Apr 13 '20 at 13:52

2 Answers2

1

All tables exist in the database that you configure in settings.py; by default that's an SQLite database in your project directory.

When running the migrate command, Django gathers all migrations from all apps you have installed (INSTALLED_APPS in settings.py). By default that includes things like django.contrib.auth, which defines a bunch of migrations related to user accounts. It's what gives you the out-of-the-box user management features of Django.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • Thanks. So if I understand you right, as long as you have classes configured in your models.py file, this alone is all Django's `migration` command needs to work with? So there's no external "list" of the way the developer has sequentially changed these classes (i.e. tables)? – mike rodent Apr 13 '20 at 13:43
  • Wrong. You define your models in `models.py`. You then run the command `makemigrations`, which automatically creates migration files in your app's `migrations` directory based on your model definitions. You could alternatively write these migrations by hand, and sometimes you have to in tricky situations. You then apply those migrations (together with all other migrations from other apps) with the `migrate` command. Whenever you change something in your models, you need to repeat these steps. – deceze Apr 13 '20 at 13:45
  • Right. Thanks. I'm following this book https://www.obeythetestinggoat.com/ ... and I've come across `makemigrations`. But the main thing was I had developed this wrongful idea that this "recipe" for making migrations was somehow kept outside the project directory somewhere. So is it right that the table `django_migrations` is kept inside the db.sqlite3 dbase along with the tables from the user's own app ...? – mike rodent Apr 13 '20 at 13:50
  • Yes. There's only one database. There's no hidden database Django has somewhere in the background. – deceze Apr 13 '20 at 13:52
0

If you use default django setup with sqlite there's a file db.sqlite3 - this is your database.

When you say it's being "regenerated" - it's being built by migrations. When you run python manage.py migrate you can see a bunch of migrations from installed django apps, including some default ones, like django.contrib.auth containing User model.

Migrations are stored within the <app_name>/migrations directory. You can check out some default migrations here, that's default auth migrations, but there are more.

Azamat Galimzhanov
  • 618
  • 4
  • 14