3 ms·

I always say this - there is no such thing as a rollback. Anyone who pretends you can simply "roll back" a stateful application is out of their mind. If you ca

by mcny 3y ago

I always say this - there is no such thing as a rollback. Anyone who pretends you can simply "roll back" a stateful application is out of their mind. If you can roll back and forward events, good for you but for most of us rollbacks are actually a new build, deployment, and a new set of tests. Every single time.

perrygeo 3y ago
The system can only move forwards. Just like a `git revert`, it's a new commit to an immutable history. This is why I've never used or understood the value of the "downgrade" feature in some database migration tools. If you need to revert, make a _new_ migration that fixes the problem. Your tooling/code/logs should reflect the true history of the system without cooking the books.
- OJFord 3y ago
  In what sense is 'downgrade' not just that prepared ahead of time? Or do you just not like the name? Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.
  - perrygeo 3y ago
    downgrade implies that such a thing is possible. In a stateful system though, you cannot take back that which you have committed. It's quite literally impossible by definition.
    - OJFord 3y ago
      No it isn't? Forward migration: add date column, set = date(day, month, year) for existing records, drop is valid date constraint, drop day/month/year columns Down migration: add day/month/year columns, add is valid date constraint, set day/month/year = appropriate datepart of date, drop date column for trivial example.
- tianzhou 3y ago
  >> This is why I've never used or understood the value of the "downgrade" feature in some database migration tools It's technically a roll forward, while to most users it's more nature to say rollback/revert
  - grecy 3y ago
    It’s moving forward to get back to where you started
- nicoburns 3y ago
  I’ve found “downgrade” mostly useful for quick iteration during local development (where you may well not care about lost data). Realise your initial cut of the migration wasn’t quite right? Run “down” then fix it, then “up” again.

by mcny 3y ago

perrygeo 3y ago

The system can only move forwards. Just like a `git revert`, it's a new commit to an immutable history. This is why I've never used or understood the value of the "downgrade" feature in some database migration tools. If you need to revert, make a _new_ migration that fixes the problem. Your tooling/code/logs should reflect the true history of the system without cooking the books.

OJFord 3y ago
In what sense is 'downgrade' not just that prepared ahead of time? Or do you just not like the name? Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.
- perrygeo 3y ago
  downgrade implies that such a thing is possible. In a stateful system though, you cannot take back that which you have committed. It's quite literally impossible by definition.
  - OJFord 3y ago
    No it isn't? Forward migration: add date column, set = date(day, month, year) for existing records, drop is valid date constraint, drop day/month/year columns Down migration: add day/month/year columns, add is valid date constraint, set day/month/year = appropriate datepart of date, drop date column for trivial example.
tianzhou 3y ago
>> This is why I've never used or understood the value of the "downgrade" feature in some database migration tools It's technically a roll forward, while to most users it's more nature to say rollback/revert
- grecy 3y ago
  It’s moving forward to get back to where you started
nicoburns 3y ago
I’ve found “downgrade” mostly useful for quick iteration during local development (where you may well not care about lost data). Realise your initial cut of the migration wasn’t quite right? Run “down” then fix it, then “up” again.