Hacker News new | past | comments | ask | show | jobs | submit login

But it is the application's business. You may not be altering the database schema from your application, but you still need to make sure that its code is in-sync with it.

This means that you will need extra tooling, and if you're DIYing you will need to write it yourself.




The effort is the same, regardless of the approach. If you're consuming a third-party database and the underlying schema changes, you'd have to patch your model definitions accordingly - or in the presented example, the dataclass definition. Creating code to dump dataclasses from a database is actually trivial.

In ORMS like Django, models are defined as code-first, not schema-first. Yeah, you can use inspectdb, but in any sufficiently complex application, odds are you need to add to the generated models any custom behaviors you already implemented, and verify all the names and whatnot, because data definition and operations on data are actually mixed in the same class. More often than not, if the change is profound (eg. imagine switching from reading a User model from the database to fetch it from an external service), you may have to refactor a large portion of your code due to the way it interacts with the model - eg. search operations won't be proxied via orm, but by using external service endpoints, etc. There is no free lunch. And don't even get me started on field names that differ on the database.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: