4 comments

  • simonw 11 hours ago ago

    https://github.com/nsrht/time-travel-sqlite-debugger/blob/ma... works by checking the mtime on the database file (and -wal file) once per second and creating a backups/unixtime_database.sqlite file if anything has changed, then keeps the last 50 copies.

    So OK for smaller database files but not great if you're pushing into a GB+ of data.

    I'm not convinced by the way it copies the files - I think using a "vacuum into" backup would be safer then file copies.

    Litestream offers point-in-time recovery for SQLite by backing up chunks of WAL directly, which I expect is a lot more efficient than this mechanism.

    • kevincox 8 hours ago ago

      It uses `safeAtomicCopy` so you know it is good.

      Of course safeAtomicCopy only ensures that the output is atomic, it doesn't lock the database in anyway. So yes, you will get corruption. It also attempts to support WAL but just copies the extra files afterwards without any locking so even more corruption.

      So I would definitely heed the warnings that this is not for production use.

    • dcreater 11 hours ago ago

      And using php of ai languages to do this...?

  • corysama 4 hours ago ago

    I can imagine abusing this to implement undo-redo for a game editor. Take snapshots. Record actions. Implement undo as: role back to a snapshot and re-run actions from the snapshot to the desired state.