4 ms·

Thanks. I always thought every project should have a few well thought out and relevant "invariants" - assumptions that it's easier to rewrite than change, that

Thanks. I always thought every project should have a few well thought out and relevant "invariants" - assumptions that it's easier to rewrite than change, that the whole architecture is built around. They can be a data structure, a library, a way data flow is structured, whatever, as long as they make the rest of the architecture naturally fall into place around them. On database-heavy projects like CRUD web-apps it makes a lot of sense for the ORM to be such an invariant. And I've never hit the point where I was sad to have my ORM so entangled with my code. So it's really hard for me to get this perspective, although I hear it so much around me. I guess my takeaway from this conversation would be to study the SQLA architecture as a shining example of correct layers of abstraction, but keep using Django ORM in practice until I encounter a situation where I wish I wasn't. How did you "bend the migration tool to your will"? What did you need it to do that it didn't do natively? What other things did you need to do that an opinionated generic ORM like Django's considered "against the grain"?

aidos 9y ago
Agree with you, and it totally depends on how the project is going to unfold. Alembic works by introspecting the db (using sqla) and then creating a script, in sqla, that migrates the current db to match the model defined in code. You can hook in to change that process. In our case, we wanted to create a fully automated Choice type using native python enums. We then added a hook to alembic so it could detect the inconsistency in between the constraints in the db and the code and update them accordingly. The whole thing is about 50 lines. There was a bit to learn, but with sqla / alembic you just slowly start peeling back the layers. Ironically that's all probably something that django has covered!

aidos 9y ago

Agree with you, and it totally depends on how the project is going to unfold. Alembic works by introspecting the db (using sqla) and then creating a script, in sqla, that migrates the current db to match the model defined in code. You can hook in to change that process. In our case, we wanted to create a fully automated Choice type using native python enums. We then added a hook to alembic so it could detect the inconsistency in between the constraints in the db and the code and update them accordingly. The whole thing is about 50 lines. There was a bit to learn, but with sqla / alembic you just slowly start peeling back the layers. Ironically that's all probably something that django has covered!