3 ms·

I really don’t follow this. It sounds like you are favouring what you are familiar with, and are back-solving a justification. You’re essentially describing a

I really don’t follow this. It sounds like you are favouring what you are familiar with, and are back-solving a justification. 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.

regularfry 3y ago
Maybe I am? I'm not sure. But there is a philosophical difference here that has practical impacts. Django says "the model file is the source of truth". Rails says "the database is the source of truth". My gut feel is that the former creates a situation where you're more reliant on the quality of the abstraction, and putting the database entirely in the control of the framework is what you expect. > 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.