Hello everyone!
I have difficulties setting up my Django project to account for shared DB tables.
More specifically, I have models that refer with a Foreign Key a table not managed by my app (different app in a different docker container).
Following Django philosophy, the solution would be to mark the Model as “unmanaged” (Meta managed = False), but that breaks my tests as migrations will try to add the Foreign Key constraint to a table that does not exist.
In my brief experience with Django, i’d like to keep migrations for those cases as they simplify the setup of a local environment starting from zero. Migrations would also help in case the other application (the owner of the shared table) changes its model.
I’ve created this issue to discuss a possible solution, but sadly it didn’t get much attention: Setup for unmanaged models in tests · Issue #168 · django/new-features · GitHub
Thanks!
Welcome @Pavinati !
There have been a couple threads here talking about this. Hopefully you might get some useful ideas from them.
Thanks @KenWhitesell !
Indeed I had a look at those, and i partially mentioned them in the new-feature post.
In the end it all comes down to dev experience using the Django framework.
For my specific use case, i decided to keep the models managed, but faking migrations in production (py manage.py migrate <external-model-app> --fake).
Of course this has disadvantages, but I’m ok with them for the time being.
The issue remains for new Django developers. If a feature is part of the framework, i would expect it to be well integrated with the rest of the framework or documented enough to not rely on third party custom code (or maybe i didn’t search well enough in the documentation).
If there is a reason why that feature is currently as it is (besides time/priorities) i’d like to know it, as it can better guide me in future decisions regarding those models
I frequently reference unmanaged tables. In these cases, these tables tend to be owned by other systems and the schemas are rarely changed. For the most part, I don’t need to worry about any migration applying to them.
When looking to test such a system, I create a “template” db with the unmanaged tables and the appropriate test data. I then create the test db from that template, allowing migrations to create/update everything else. (I use PostgreSQL, I’m not sure how well this concept would translates to other databases.)
<opinion>
Personally, I would say that Django is doing the right thing for the situation being presented. As far as I’m concerned, identifying a model as “unmanaged” means precisely that - by default, Django should do nothing related to that table - the developer is assuming 100% responsibility over everything concerning it.
</opinion>
I create a “template” db with the unmanaged tables and the appropriate test data
Does Django have a way to define what’s the “database template” to be used during tests?
For this template to work, it will have to be setup before migrations, otherwise migrations will fail when trying to create Foreign Keys to those unmanaged tables.
Actually, it doesn’t have to be a full database template, it could be just some custom SQL where the developer has responsability of creating everything necessary.
[…] identifying a model as “unmanaged” means precisely that - by default, Django should do nothing related to that table - the developer is assuming 100% responsibility over everything concerning it.
I agree, but to an extent. It’s should be 100% responsibility of the developer, as long as the framework provides the right handles to do manage it. For example, a meta function with the custom template to be used; pre-migration signals for test setup; TestCase fields that allow custom setup (always before migrations) etc.
I’m too new with Django to provide meaningful suggestions, here i’m just brainstorming what feels ok from my point of view
I’d guess there’s probably a hook somewhere that you could tie in to, but I haven’t bothered looking for one.
But again, my perspective on this is different. For a couple of reasons, with the unmanaged models being one of them, I don’t have the test suite create the test database. I do that external to the tests. That’s just part of my workflow - I find it’s a lot more effective for me that way.
I’m sure this puts me outside the “common case”, but I find it a lot easier to manage my test database using other tools.
(Side note: I’m working with a system having an installed base of 2 - and I control both of them. I don’t need to concern myself with supporting other individuals who may need to perform upgrades, nor need to address any of the hundred or so issues across supporting multiple installations of a project. That gives me the ability to be a lot more focused on precisely what I’m testing and how I need to handle it.)