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?