You’re essentially describing a declarative migration system which on the face of it sounds reasonable. It sounds like you’re dismissing it on this property. After all, the underlying DDL is…declarative, for the initial tables, anyway.
When you create a new migration, Django will tell you which actions it’s written into the migration file, i.e. the actions it thinks need to be taken to get from A to B. I don’t see anything opaque about that?
You can also look at the migration file yourself. It’s entirely readable. You could even write your own if you wanted to.
The Rails community seems to still be carrying a very peculiar compete-with-Django attitude from back in the heyday. I see it all the time here. It’s ridiculous.
> When you create a new migration, Django will tell you which actions it’s written into the migration file
Yes, that's the point. With Rails, I tell it what to do, and if my start point is a specific change I want to make to the database, that's an easier starting point than having to first translate the problem from the database into the model, so that the abstraction can convert it back again, for me to double-check.
The specific example I've got in mind is database migrations. The default with Rails is that you write them yourself, and the model then interpolates what it finds in the database at runtime. With Django, the pattern (again, by default - but defaults matter) is that you change the model and the migrations are generated automatically. The model is the source of truth.
I haven't figured out exactly why yet, but the way Rails splits the responsibilities seems to be much cleaner to me. I'm always slightly uncertain about what Django is going to do. With Rails the database feels closer to the surface, rather than something handed entirely over to the framework.