Django migrations orphan tables

Using Django Using the ORM
1

Django migrations orphan tables

Orphan tables: Tables that are not found in models & migrations files

Context

I have a few orphan tables.

I dug through git history. The reason is because I renamed the app and replaced the table names in all files using sed.

I must have done

  1. ./manage migrate → create orphan tables
  2. Renamed app and replaced these orphan table names
  3. ./manage migrate → still works instead of conflict / corruption because the app is renamed

Main

My orphan tables are empty, so I can deleted them directly without consequences.

But is there any django management commands that can help us identify orphan tables?

Would be great if we have built-in tools for this

For e.g. ./manage showorphantables, ./manage droporphantables

2

But what defines an “orphan table”?

Django is not a database management tool. It does not create the database. It also does not have exclusive control over the database. It doesn’t even necessarily have exclusive control over the tables it uses, much less tables that it doesn’t use.

It’s a really bad assumption to ever assume that any table not being used by a particular project are “orphan” or “unnecessary”.

<opinion>
I don’t think so.

I think that has the tendancy to become a very dangerous situation.

I definitely would not want it to be part of core.

If someone wants to create that as a third-party package, fine. But I would never use it.
</opinion>

3

I get what you mean. Which comes to a new point, would be great if there is a strict mode setting. Where Django has exclusive control over the database. When migrations is the only source of truth, it makes my assumption safe.

I would still like to see if anyone has any commands to do the check, doing it manually for orphan tables is not an easy task.

4

Again, an exceedingly bad idea, this time from a security perspective.

Aside from (perhaps) sqlite, there are more tables in any database than what you might think. Exposing them to an application is just asking for problems. It’s also why you should never run Django using a database’s “superuser” account. Django isn’t the right tool for that job.

If you’re looking to just identify immediately-visible tables with what you have models defined for, you could probably build something on top of the inspectdb command.

5

Aside from (perhaps) sqlite, there are more tables in any database than what you might think. Exposing them to an application is just asking for problems. It’s also why you should never run Django using a database’s “superuser” account. Django isn’t the right tool for that job.

I just learned something new. Thanks

For learning purpose, is there any tool that has exclusive control about the database? A tool that can handle migrations from multiple frameworks (Django, Ruby on Rails etc) and manual table creations. Can’t imagine how it works. Or it’s still up to us (human) to ensure?

6

Yep. Only a human can know what the usage of tables are in any system.

For example, I’ve got two related systems running against the same database. Some of the models are shared, most aren’t. Some are even used externally to the two Django projects. I don’t see how any automated tool is going to be able to address something like that.

1 Like