1👍
Unfortunately in the situation described you don’t have very many good options, but a celery beat task to ensure the existence of the extra OneToOne will either fire way too often using a ton of resources for nothing, or not fire often enough and there are time delay gaps you have to code for. I’m sure you’ve also evaluated that modifying the database and adding triggers could have a number of unexpected and undesired effects in the legacy code.
My instinct in the situation is to modify the constructor, but Django really discourages changing Model constructors for various reasons. However, we can still achieve this functionality by connecting to formal signals Django fires off. You’d be looking at a pre-init signal or possibly post-init you’ll have to test.
https://docs.djangoproject.com/en/4.2/ref/signals/#pre-init
In theory if you connect code to the pre-init signal of the original model it could call out to extended model table and ensure the relationships necessary exist before any code fires to work with the model. I think this approach would much more closely achieve what you’re attempting to enforce without a lot of extra hassle and dead network calls.
Also feel free to tell your boss I personally +1 nuking that legacy app in favor of a properly written Django app. The situation described is one where I’d happily declare technical bankruptcy.