[Feature Request] Let manage.py ignore migration dependencies

[Brock Hallenbeck]

We are a municipality using Django to make a CRUD tool. Our use cases are usually some department in the town wants to do CRUD stuff so they come to us. Our dream is to make an app, plug in some models and be mostly done. However it is very common for us to need to use different databases. Due to the lack of cross database foreign key relationships this means we will have to make a copy of our project every time we need to use a separate database because in our CRUD project, every object that is created has a '_created_by' field that foreign keys to User. 

After some digging I have found that using Postgres' foreign data wrappers, I can designate and 'auth' database, and have other databases access it's tables as their own. Using database routers I write to the auth database and read from the app database. This results in all our apps using all different databases can consult the auth database instead of local auth_* tables which would be out of sync with any other app we have.

As far as I can tell this is working. However setting this up was a bit of a hassle. After creating the auth database by getting the auth_* and django_* tables set up, the next step was setting up my first app database.

In our case, we have a base model that every single model we write subclasses, this model simply adds some utility fields that we like, namely 'created_by' and '_last_updated_by'. These are fields that foreign key into Django's 'User' model. The result is that for every single application we deploy, when we migrate, due to dependencies, we get the app's tables, and all the auth_*, django_* tables. 

Due to these duplicate tables, my process of setting up an app database is as follows:

1.Create database on server / point django at it / set up router

2. migrate <app> --database=app_db

3. Delete all the duplicate auth_* and django_* tables

4. Run FDW script importing auth_* and django_* tables from auth_db

If I could do something like python manage.py migrate <app> --database=app_db --ignore-dep I could do something like:

1. Create database on server / point django at it / set up router

2. Run FDW script importing auth_* and django_* tables from auth_db

3. migrate <app> --database=app_db --ignore-dep

I could probably streamline steps 1 and 2 somehow. 

I understand that without the dependencies the sql output might be invalid as the tables don't exist. I am essentially asking for the ability to deal with the repercussions of not having the correct tables present in the database myself. 

All thoughts and criticisms welcome.

[Shai Berger]

Hi,

On Thursday 13 April 2017 18:18:57 Brock Hallenbeck wrote:
>
> Due to these duplicate tables, my process of setting up an app database is
> as follows:
>
> 1.Create database on server / point django at it / set up router
> 2. migrate <app> --database=app_db
> 3. Delete all the duplicate auth_* and django_* tables
> 4. Run FDW script importing auth_* and django_* tables from auth_db
>
> If I could do something like python manage.py migrate <app>
> --database=app_db --ignore-dep I could do something like:
>
> 1. Create database on server / point django at it / set up router
> 2. Run FDW script importing auth_* and django_* tables from auth_db
> 3. migrate <app> --database=app_db --ignore-dep
>

> All thoughts and criticisms welcome.

Instinctively, the process I would expect is:

1. Create database on server / point django at it / set up router
2. Run FDW script importing auth_* and django_* tables from auth_db

3. migrate --database=app_db --fake auth # etc
4. migrate <app> --database=app_db

Why does that not solve your problem?