I am looking for a way to dynamically destroy (delete) a dynamic model. I am creating a model via the type operator. Everything works perfectly. When I delete a model, I do the following sequence of actions:
- I get the model by calling:
model = apps.get_model(app_label, name)
- unregister model from the
registry of the admin site
- delete the model from the database:
schema_editor.delete_model(model) (successfully)
- deleting the model:
del model
- clear the application cache:
apps.clear_cache()
- сlear
ContentType
- сlear the cache of the admin site:
reload (import_module (settings.ROOT_URLCONF)) clear_url_caches ()
But, after all these actions, the model surprisingly remains in the memory. For example, this can be seen in the nested form on the admin site. Referring to it, of course, leads to an error, since by this moment the corresponding table is no longer there.
If I reboot the server, the model disappears because there is no entry in the model factory. I shouldn’t reboot the server every time.
Am I doing something wrong?
Yes. Django is not designed nor intended for models to be dynamic. There may be any number of internal data structures assuming that every model that exists when the framework initializes is going to be there throughout the lifespan of that instance.
There’s also no guarantee that any workaround you identify now is going to be valid with the next version update.
Also keep in mind that in a production environment using something like uwsgi, you’re likely to have multiple instances of Django running. Anything you do to clear out cache or reload modules will only be done in the instance in which that work is performed. It’s not going to do the cleanup of the other instances.
Ken, thanks for the answer. Well. All that remains is to regret.
Well … you will probably find it wrong to think that, nevertheless, the django developers, when providing the ability to dynamically create a model, should think about a mechanism for destroying the model.
Well, we’ll think of something.
Thank you again for your reply.
Hmmm… what “dynamically create a model” functionality are you referring to? I see nothing in Django providing that facility.
Yes, if you look at Django Packages : Dynamic models, you will find 4 third-party modules implementing that. But they are not part of Django - they are third party modules outside of Django.
Ken, honestly, I don’t want to argue.
About the ability to create dynamic models. There is at least this:
https://code.djangoproject.com/wiki/DynamicModels
Yes, this is decrepit old stuff, and an illustration.
As for all these packages, of course, we researched these packages. Unfortunately, none of them are suitable for solving our problems. Moreover, the mutant uses openly hacker techniques, which is absolutely unacceptable.
I understand that the developers thought well for me, and decided that I didn’t need dynamic models (yes, that’s sarcasm). Not scary. We’ll try to parse the source code and find an acceptable solution.
Thank you for the answer. We didn’t think it was impossible (this is actually shocking). Now, knowing this, we have already found a couple of methods to avoid mistakes. One is not very beautiful (calling migration commands), I reject it. The second is the customization of the model manager, which will check if the model is not deleted. Also not pretty. Now guys parse the source code, looking for what “reanimates” the model (as a class) after “hard” Pythons’
del model
gc.collect()
We will solve the problem!
Thanks again!
This isn’t an argument - it’s discourse with an eye toward knowledge, understanding, and education.
For example, from the page you quote:
Drawbacks
While dynamic model creation has incredible potential, it should not be considered a recommended way to go about model declarations. Most projects won’t find any value in it, and those that do have a bit of work making sure their definition scheme is robust enough for their needs. In addition to the decision of whether to use them, there are a few other details that somewhat hinder their use.
Clearly, even the authors of that wiki page acknowledge it’s not a recommended process.
Obviously, you can implement anything you want from the code base - it’s your copy after all. And if you get it working, stable, and reliable in a production-quality deployment environment, I’ll be the first to stand up and cheer your efforts.
All you’re getting from me (and anyone else choosing to chime in) is the acknowledgement that this isn’t something Django is designed to do. (Whether or not it should be is a different issue that you don’t see me addressing - I make no value judgements on how things are or should be.)
I’m also passing along the warnings from those that have tried things like this before that it’s not going to be as simple as you think it’s going to be, and there are a number of potential pitfalls with any approach you choose now, going into the future.
Keep in mind that any changes you make to core will also need to be tested and validated on any third party packages you may choose to use.
Good luck!
1 Like