indeed, I was thinking about the same. How do you even escape the hatch with e.g. Atlas if your migrations folder is autogenerated? What if you modify /migrations but not your entities?
indeed, I was thinking about the same. How do you even escape the hatch with e.g. Atlas if your migrations folder is autogenerated? What if you modify /migrations but not your entities?
you do what I do!
1. Generate the migrations and commit them to git
2. Have your codegen use diff3 so users can modify the generated files, or fill in details to partially generated code
3. Give users a way to indicate they did this so you don't break things later with codegen
Most often the gap is about indexes or wierd database quirks than fields on an entity.
Also, make sure you are generating the migrations AND the entity implementations in code from the same source-of-truth. Similar to how people commit the migration history to git, I have hof commit the data model history to git (and the codegen'd output without changes, double files are worth the bloat). By doing this, you can also generate the code that moves data between schema or api versions. (i.e. data lenses a la ink&switch)
cool!