3 ms·
I can describe how Django addresses the issues that you raise: 1. You can squash the migrations, or delete them all and start afresh. I have had to do this jus
by QasimK 8y ago
I can describe how Django addresses the issues that you raise:
1. You can squash the migrations, or delete them all and start afresh. I have had to do this just once on a project after it was 4 years old, and it was easy to do (ie. it is relatively infrequent).
2. You can experiment by creating new migrations, and, when you’re done, rollback and create the one you want.
The third point I cannot address, as you were very much using Python/Django and I cannot imagine an easy way to use the database models cross-project. I would probably argue that you shouldn’t do this.
However, Django’s approach was largely declarative, but in Python not SQL. Further, the migrations were automatically generated as Python which made them easy to modify.
- evanelias 8y agoSure, but what happens when your company gets big enough to have backend systems/projects/tools in multiple languages? I've seen this at countless companies, and in my experience it gets ugly fast. You can either shoehorn all schema changes into Django (for example) even for non-Python projects, or you can have different processes for each language, but either way that's a losing proposition vs having a unified, language-agnostic tool. The migration systems built into frameworks like Django and Rails are truly great for rapid development, but they can become a quite a burden later on.