4 ms·
https://github.com/nsrht/time-travel-sqlite-debugger/blob/main/watcher.php https://github.com/nsrht/time-travel-sqlite-debugger/blob/ma... works by checking the
by simonw 2mo ago
https://github.com/nsrht/time-travel-sqlite-debugger/blob/main/watcher.php 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.
- dcreater 2mo agoAnd using php of ai languages to do this...?
- kevincox 2mo agoIt 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.
- nsrht 2mo agoI'm currently testing SQLite's native VACUUM INTO. I'm also adding explicit busy handling so the watcher skips a snapshot rather than blocking the application