Having South take that leap into Django core will be awesome.
I'll bet one natural result of it entering core will be better shared understanding of best practices & foibles of different backends.
Managing migrations on increasingly large tables is stressful for me primarily due to my lack of knowledge, moreso than fragility in any piece of the puzzle.
In any case, I've thrown in my pledge - best of luck!
(If anyone has any good recommended reading for DBA-type knowledge in a devops world, I'd love an Amazon link you think is worthwhile.)
> Managing migrations on increasingly large tables is stressful for me
large like lots of fields or large like millions of rows? if the latter, than migrations are a PITA and you'll often find inserting a select into a recreated new table is faster than altering the existing one. but that's probably not something a migration tool like this should/could support without lots of your work anyway.
Rows, not columns. But more so than really large tables, I find MySQL will tip over even on smaller tables, not very hot tables, if I want to do the work without downtime.
(It may well just be my environment, but it is fairly standard RDS on AWS.)
It's a limitation of MySQL unfortunately. MySQL does schema changes by creating a new table with the new schema and copying the old data into it and doing an atomic switch over. The table gets locked for obvious reasons.
Percona has pt-online-schema-change [1] but I have no experience with it or if it works on RDS.
There are other solutions. The most simple is doing the table rewrite yourself (but risking losing data). The more complex is to have a buffer/queue that can hold requests until the migration completes but this only works in certain specialized situations.
I'd love to find a better solution to migrations in MySQL. I've had migrations take 15 minutes on a relatively small table (2M rows). I'm a little scared to try pt-online-schema-change for fear of corrupting the db.
I would switch to PostgreSQL (nothing but love for that database from me) but the ORM I'm using has issues with identifier quoting and I can't use my "user" table with it.
We were using PGSql at the beginning of this project, but I was lured by the automatic backups / restore capabilities that RDS provides and I migrated.
One of my co-workers used to pound on PGSql pretty hard in a very high traffic environment and has nothing but good things to say, but I'm not crazy about the idea of having to learn all of PGSql's foibles like we have MySQL.
My impression is that MySQL 5.6.x (we're on 5.5.x) should help with the schema migration pain, but I don't have any hard evidence for that claim.
My hope is that MYSQL 5.6.x will remove a lot of the pain, but I don't have a
I'll bet one natural result of it entering core will be better shared understanding of best practices & foibles of different backends.
Managing migrations on increasingly large tables is stressful for me primarily due to my lack of knowledge, moreso than fragility in any piece of the puzzle.
In any case, I've thrown in my pledge - best of luck!
(If anyone has any good recommended reading for DBA-type knowledge in a devops world, I'd love an Amazon link you think is worthwhile.)