Simply monkey patching the model to add a field isn't sufficient, because you'd still need that app to create a DB migration for that field to appear in the actual database. (It doesn't seem like you're trying to add a field or a behavior purely on a Python level, because for that monkey patching, or a @property
or a proxy model would have worked fine)
Let's say you do come up with a "hack/script/solution" to migrate the DB, you will be using that app in a version that is different from the official one, so in the future when you'll want to upgrade the app's version, you can run into issues.
Fork your own version and use it as a dependency
So if you don't mind diverging* from the upstream official app, I would fork the app. Meaning I clone their repository, add my field into the model in their models.py
, generate the DB migrations, commit all those back into the repository. Then instead of installing the official app, I install my version into the virtual environment. (pip
can install from Git e.g., your app doesn't need to be on PyPI)
*Who knows maybe the app's maintainers will accept a pull request from you and put your changes in the official repo
Subclass the model
If it works for you, you can also subclass the original model, add the field you want. So your app can use the extended class you created, and the original app can use the fields/methods that already existed in its original model.