3 ms·
> in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one c
by resoluteteeth 3y ago
> in the case of sqlite though, the technology is often used as a standalone file format. So it is very tempting to consider the ".sqlite" file to be the one containing all the data, and all the rest to be temporary files that don't matter much.
If you're using it as a standalone file format you presumably shouldn't leave .sqlite files with associated wal files lying around in places where users are going to get confused by them, either by sticking to the rollback journal mode or by using some other method
- fauigerzigerk 3y agoIf you use sqlite as a standalone file format for an app that has user managed files then it is hard to avoid this confusion. Rollback journal mode creates a temporary file as well. Also, a scheduled backup process might come along at any moment and non-atomically copy the database file and any -journal or -wal files. Ideally, user visible files should survive copying at random points in time without corruption and without losing too much recent data. Having read "How To Corrupt An SQLite Database File"[1], I'm still not quite sure how to achieve this. [1] https://www.sqlite.org/howtocorrupt.html https://www.sqlite.org/howtocorrupt.html