3 ms·

> after recovering from a Clade-generated bug, I was thinking to myself “wouldn’t it be nice if prod DB writes were easy to roll back”. Hmmmmmm...... 1. "Clau

> after recovering from a Clade-generated bug, I was thinking to myself “wouldn’t it be nice if prod DB writes were easy to roll back”. Hmmmmmm...... 1. "Claude-generated bug". No it was PBCAK (Problem Between Chair And Keyboard) a.k.a "foolish person ran Claude against the production database without testing it elsewhere". There, fixed it for you. 2. This "product" is solving a problem that is already solved. You can for example use a SaaS provider such as Aiven[1] who will provide you with PITR (Point-In-Time Recovery) point and click solutions. Alternatively there is more than one piece of Postgres backup software that lets you do the same on a DIY basis. 3. "Out of the box" you have pg_dump. You could have just done a simple pg_dump before letting Claude loose on your database. [1] https://aiven.io/ https://aiven.io/

MarceColl 12d ago
I have no relation to the project, but calling this problem solved and then offering a vastly inferior solution to the proposal (PITR) is a bit unfair
- traceroute66 12d ago
  Point one remains. The "solution" appears to come from somebody who thinks its OK to run Claude against a production database.... “wouldn’t it be nice if prod DB writes were easy to roll back” The point remains that if they ran Claude against a test database they would have found the bug without killing their production database, and therefore also not need to come up with an over-engineered "solution". Sometimes also the less over-engineered the better. Stuff like PITR and pg_dump is battle-tested and easy to reason about.
  - MarceColl 12d ago
    Fair enough, but I think there is utility beyond this. Sometimes humans do stupid shit too.
  - badgirl321 11d ago
    [dead]