Admin integration is broken when using ORM as a broker with a different database

[mohmyo]

Hello,

I'm using ORM as a broker and I have exactly followed the same steps mentioned at the docs regarding using a separate DB for django_q and applying migrations.

However, when browsing admin dashboard I always get relation "django_q_schedule" does not exist when trying to open anything under DJANGO_Q section except for Queued tasks, this was clearly about that it doesn't use the correct DB, so I looked at admin.py and my guess was right, using() connection is only respected with QueueAdmin and others are not at all, I have even tried to add using() for TaskAdmin and it worked as expected, so it is all about that.

I'm using Django 2.2.16 and PostgreSQL 12.3

[Koed00]

Good spot. Seems like an easy enough fix.

[Koed00]

Now that I look at the code a little bit more - I see that the QueueAdmin is really only in case you are using the ORM as a broker.
All the other admins should use the default database. Are you sure you ran migrations on your default database?

[mohmyo]

No, I didn't run migrations on my default database why should I do so if I'm using a separate DB for django_q? I ran migrations on the other DB as docs pointed out:

if you need better performance, you should consider using a different database backend than the main project. Set orm to the name of that database connection and make sure you run migrations on it using the--database option.

[mohmyo]

I have been thinking about this for the past hour and I still can't find any reasonable reason why migrations should be run twice on two databases, I understand it may be a design thing for admin integration for other brokers but in practice, it should be all in one place in this case.

[mohmyo]

@Koed00 some clarification would be much appreciated, I really need to understand why migrations should be applied to two databases

[pfgoting]

Hello! Sorry for resurrecting this old thread since I just encountered the same issue as the original poster. So if my understanding is correct, when using another database as a broker, all task-related data except Queued tasks are still saved on the default database. Therefore, 2 migrations need to be run. The first migration is to have django_q_schedule and django_q_task on your default DB, while the second would be for django_q_ormq on your broker database.

I think this was designed such that even when changing brokers, the task data would remain intact on only one database. Think of a scenario wherein you started using another DB as a broker but then switched to Redis. This would result in you still keeping the separate broker database even though it outlived its main purpose already.

[xucian]

this is unintuitive. I also discovered this also holds true when using redis as a broker? at least according to 'manage.py migrate' which modifies my main db