3 ms·

EDIT: By 'not possible' I mean it's not possible to delegate responsibility for it to a tool that derives what the differences in schema are. Schema migrations

EDIT: By 'not possible' I mean it's not possible to delegate responsibility for it to a tool that derives what the differences in schema are. Schema migrations are not possible in general. Yes, you can diff two schemas and generate statements to turn one into the other. Adding columns works fine this way. Removing columns works fine. Do you really need a library to add and remove columns? Not really. But rollback, someone will say. Schema migration libraries let you undo things. Nope. You can't rollback a drop column once it is committed, that data is gone. What happens when you run into issues in production that you didn't have in your test/development environment? Basically, automated schema migrations don't work. However, I guess if you haven't been through it you'll just have to learn the hard way. :) SQL gives you a very flexible environment. You never have to break existing code to push out new features, if you are just a tiny bit careful.

haeric 14y ago
Well, do you EVER actually need a library? No, mostly you can always do stuff manually. But South makes a lot of stuff easier/less brittle, especially when you have a) multiple servers, b) multiple developers, c) multiple environments, and/or d) volatile data structures. It is also useful to see what database changes a pull request introduces. And don't get me started on data migration, which is TRULY easier in South, if you are working with multiple branches/developers and/or have schema changes as well. South certainly has it's warts, but that's why I'm happy to contribute to Andrew's project. Oh, and rollback: Depending on what the data is, it might actually be possible to rollback. It might be an aggregate column of some sort, or moving of data from one table another. But it's mostly not superuseful, and it's not a big part of the awesomeness of South.

haeric 14y ago

Well, do you EVER actually need a library? No, mostly you can always do stuff manually. But South makes a lot of stuff easier/less brittle, especially when you have a) multiple servers, b) multiple developers, c) multiple environments, and/or d) volatile data structures. It is also useful to see what database changes a pull request introduces. And don't get me started on data migration, which is TRULY easier in South, if you are working with multiple branches/developers and/or have schema changes as well. South certainly has it's warts, but that's why I'm happy to contribute to Andrew's project. Oh, and rollback: Depending on what the data is, it might actually be possible to rollback. It might be an aggregate column of some sort, or moving of data from one table another. But it's mostly not superuseful, and it's not a big part of the awesomeness of South.