3 ms·
This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale appl
by sontek 10y ago
This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale applications as a way to say that everyone who can't do that are using bad frameworks.
Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable.
We allow developers to run generated migrations in dev/testing environments but when its time to go to staging we evaluate the changes made and check query plans and figure out what type of locking is going to happen and how long it would take it prod. There is very few times the migrations Django or Rails generate are acceptable at our scale in production.
- caseymarquis 10y agoI think you're correct. I was out of line by being too general. For our large scale applications we back up the database and have required down time from our customers while doing a major migration. Everything isn't always simple. But adding a check box in 90% of cases usually is.
- sontek 10y agoAdding a check box in a relational database most likely involves running ALTER TABLE to introduce a new column which in most relational databases locks the table. Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.
- caseymarquis 10y agoI conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.