I've recently inherited a project where the database was modeled interestingly (i.e. lack of some index and foreign key definitions). The project uses GORM and from what I can tell, those Models have tags which define everything correctly.
I can't think of a reason why using the ORM for database "modeling" wouldn't work. The closest I can come is performance, but at the scale this would need to run, the point seems moot. Are there any downsides to this running things this way?
The only downsides I'm aware of from doing the same thing at my company are:
AutoMigrate you can get tables, columns, and indices created, but you can't add in default data or write a data transition, nor will it drop columns, nor does it keep a history of changes. If all the developers use the same dev database this isn't too much of an issue, but if you start having separate dbs you'll probably start keeping migration sql files around too, which you'll have to manage separately from Gorm.I don't regret using it initially as it was much easier to declare the model and the sql in one place to start, but as we grew and started to use more advanced sql features and more databases, we had to switch to doing actually schema definitions and migrations.