4 ms·
For me, the biggest reason not to do this sort of thing is that SQLite still often refuses to work over network filesystems. I appreciate that this is because
by mjw1007 9y ago
For me, the biggest reason not to do this sort of thing is that SQLite still often refuses to work over network filesystems.
I appreciate that this is because the authors are being careful about possible corruption when locking isn't working properly, but if they really mean the « SQLite competes with fopen() » line they need to find a way to get round this, because fopen() doesn't do that.
- nikbackm 9y agoWouldn't fopen and friends also have issues when locking isn't working properly?
- mjw1007 9y agoThey might well lead to file corruption if two people try to save the same file at once. But that tends not to matter in practice for applications like word processors (which often want to implement their own system to stop two people opening the same in editable mode at the same time, not just stop them saving at the same time). Or the fopen-using application can just do things the simple way and write out a new temporary file to replace the old one with.
- wruza 9y agoThe same way sqlite-using app could write a new database file and replace the old. What does this argument support in this subthread?
- mjw1007 9y agoThen you lose many of the advantages being touted in the « What If OpenDocument Used SQLite? » page that we're discussing. Consider the following paragraph: « Hence, "File/Save" takes longer than it ought, especially on older hardware. Newer machines are faster, but it is still bothersome that changing a single character in a 50 megabyte presentation causes one to burn through 50 megabytes of the finite write life on the SSD. »
- PaulHoule 9y agoAmazingly, the Jet engine in Microsoft Access (a file-based database a lot like SQLite) works very well over Microsoft's network filesystem, but it helps that file locks in Windows are much more solid than file locks in Linux. (The tradeoff is that Windows machines go out to lunch every so often) This document http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart3.pdf http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XM... is a great overview of a number of desktop and media file formats (particularly in the context of how to find holes in them in which you can stick metadata.) Read between the lines and you can understand some of the tradeoffs; the database-based format shows up once or twice and, from the viewpoint of XMP, it is the one in which it is hardest for a foreign program to find an embedded media packet. On the other hand, SQLite is open source so you can say "just open it with SQLite".
- WorldMaker 9y agoModulo the fact that friends don't let friends use Jet in 2017. ;) Microsoft hasn't supported Jet in forever (a decade or more), and doesn't recommend it. The number of corrupted MDB files (and stranger, corrupted LDB lock files) I've had to work with in the last couple of years (in trying to migrate Jet-using VB6 apps to something 2017 has to offer) has shown me wisdom that Jet/MDB is a database format that should be properly thanked for its service over the years, then gracefully old yellered.
- deleted 9y ago[deleted]
- catdog 9y agoYou can opt out of being careful: https://www.sqlite.org/uri.html#recognized_query_parameters https://www.sqlite.org/uri.html#recognized_query_parameters
- mjw1007 9y agoThanks, that's good to know. So a word-processor-like application might try implementing its own simple global lock (eg with a lock file) and then tell SQLite to use nolock=1. I'm not sure I'd feel very comfortable doing that but it seems OK in principle. I wish Subversion would offer an option to do something of the sort for its working copies, now it has an SQLite database in there.