Why do we need to subclass db.Model, not DeclarativeBase?

[Alan-Liang]

The database models in our application is shared with other non-Flask components, i.e. the layout looks like this:

project/
  common/
    models.py
  web/
    app.py
  some_other_component/
    cli.py

It is natural that I do not want to include Flask in non-web contexts (i.e. in some_other_component), but the models need to subclass db.Model, which is introduced by FSA. What is the recommended way to do this?

[ThiefMaster]

there's absolutely nothing wrong with loading a flask application context in non-web parts of your application. in fact it's usually a good thing to do because that way you have the same environment (config etc) everywhere.

[Alan-Liang]

IMHO it's absolutely bad to load an entire web framework only to reuse database models; they are not part of the web application. In fact, in my case, other parts should not share config with the web server, e.g. other parts should not be able to read secrets used by the web server.

That aside, what is the technical point of subclassing db.Model? Which features would be impossible without it?

[pamelafox]

Flask-SQLAlchemy adds on features like get_or_404, a useful function for views. It also includes auto table naming and bind mapping. It sounds like you might be happier using SQlAlchemy without any wrapper.

[pamelafox]

I have an example here that's similar to that layout:

models.py:

https://github.com/Azure-Samples/azure-flask-postgres-flexible-aca/blob/main/src/flaskapp/models.py

init.py which uses app factory pattern:
https://github.com/Azure-Samples/azure-flask-postgres-flexible-aca/blob/main/src/flaskapp/__init__.py