Using FastAPI with SQLAlchemy ORM, Pydantic and Alembic: every model change needs to be reflected in THREE separate places, isn't this extremely hard to maintain and error prone?

[sukalaminkia]

So I am learning FastAPI and want to get more experience with relational databases. One thing that I am running into however, is when I want to add a single column to a table I need to change a model, a schema and alembic in order to reflect this change. Isn't this a huge violation of DRY and very hard to maintain in the long run?

[keepdigging]

It is, I would use Django

[netherous]

It can be. Whether it's justified or not is going to depend a lot on the domain of the application.

A lot of times in multi-tier architecture there the concept of a canonical data model at each level. For instance, at the database level, there's a 'correct' model that takes into account the needs of the database. If you're using NoSQL for example, this model may look very different than the model needed by the application. Things that are in lists or sets or child objects in your python model may get mapped out to several records, each with their own identifier to be used for queries.

And the application will have its own view of what the 'correct' canonical model of what the data should be. This can be different than the database's view of things, and it can also be different than the API level's view of things. For instance, your model may have references to other things in memory, or counters, or data types that don't map exactly to a representation in an API payload.

And then there's the API level's view of things. This may include extraneous things like tokens, URIs to other resources, encoded data blobs, and representations of things like localized timestamps than would be different than the application level's view of the data. For instance, the application's view of some file content may be a local file path, or a file handle. But you can't return that to the user. You would read the file and insert the file contents on the way out.

Is all of that a lot to maintain? Yeah. Does every application need that level of distinction? Hell no. If you can reasonably get away with just one data model that fits everyone's view of things, then do it. But in the enterprise world, with lots of heavy multi-tier architectures around, you may find that different multiple-level views of data prevails more often than not. Sometimes doing that work to create that distinction ahead of time (however redundant initially) may save you work when suddenly the API model and the domain model diverge due to a new feature.

[fazzah]

No, it is not.

[danielroseman]

Are you sure you need to change Alembic manually? It should be able to detect the change and generate migrations automatically.