3 ms·

have you seen sqlite official documentation on corruption resistance? https://www.sqlite.org/howtocorrupt.html https://www.sqlite.org/howtocorrupt.html support

by theamk 3y ago

have you seen sqlite official documentation on corruption resistance? https://www.sqlite.org/howtocorrupt.html https://www.sqlite.org/howtocorrupt.html supported failure modes, tested and handled: "application crash, or an operating-system crash, or even a power failure" - so basically proper atomic renames. git does this well. unsupported failure modes: "Backup or restore while a transaction is active" - when you backup your machine, do you really treat each sqlite specially? I know I don't. "Deleting a hot journal" - or, you know, downloading database file and forgetting to grab journal at the same time "Multiple links to the same file" - did you ever hardlink or bind-mounted a database file? prepare for corruption... ----- Don't get me wrong, it takes some skill to implement proper safe file handling, and a random person off the street would be better off with sqlite. But git specifically took the effort and designed the system so that the database is resilent in all sort of crazy conditions, and even if not, it's easy to recover. Switching git to sqlite would be all downside, no upside.

charcircuit 3y ago
>when you backup your machine, do you really treat each sqlite specially? Yes, but only for servers where the database is being used. On my desktop if the database isn't being used it is safe to copy so I don't worry about it. Backing up a git repo while git is writing to the repo isn't safe either. >or, you know, downloading database file and forgetting to grab journal at the same time You should not be downloading an actively used sqlite database anyways. If you backup the sqlite database before downloading it there won't be a journal file. >did you ever hardlink or bind-mounted a database file? prepare for corruption... You just have to link both the database and WAL file. This is somewhat challenging since the WAL file will be deleted by default if all processes close the database. It's better to link or mount the directory that contains the database file. If you link only some of the files from .git, then git won't work properly either.

by theamk 3y ago

charcircuit 3y ago

>when you backup your machine, do you really treat each sqlite specially? Yes, but only for servers where the database is being used. On my desktop if the database isn't being used it is safe to copy so I don't worry about it. Backing up a git repo while git is writing to the repo isn't safe either. >or, you know, downloading database file and forgetting to grab journal at the same time You should not be downloading an actively used sqlite database anyways. If you backup the sqlite database before downloading it there won't be a journal file. >did you ever hardlink or bind-mounted a database file? prepare for corruption... You just have to link both the database and WAL file. This is somewhat challenging since the WAL file will be deleted by default if all processes close the database. It's better to link or mount the directory that contains the database file. If you link only some of the files from .git, then git won't work properly either.