I’m having difficulty reconciling the advice in the createProcedure documentation .
Often times it is best to use the CREATE OR REPLACE syntax along with setting runOnChange=’true’ on the enclosing changeSet tag. [...] The advantage to this approach is that it keeps your change log smaller and allows you to more easily see what has changed in your procedure code through your source control system’s diff command.The advantage is pretty clear, but the disadvantage is that rollback becomes a big headache. If you roll out a migration that breaks in an unforeseen way, you need a way to get the old version(s) of the procedure back again.
One approach I can imagine to deal with this is to copy the previous version of the file to a “rollback” file, which is fine as far as it goes, but has two problems. The first is that developers have to remember to do this; this can be mitigated with comments and code reviews, but is still a concern. The second is that you only get one level of rollback with this approach. Once you rollback a “re-run” migration, the change set is gone from the database change log table.
How do people handle this? Are you following the advice on the docs and accepting that rollback is difficult to manage, or do you ignore the advice and put migrations of procedures into separate files?