> On Oct 24, 2017, at 8:14 AM, Arno Gramatke <ar...@meyersound.com> wrote: > > My first naive approach was to figure out, which commands will result in a > read and which will result in a write to the db file.
I think you’ll need to assume that any SQLite access can both read and write the file. So at a high level, you should use the NSFileCoordinator to request access before an activity that can cause queries or database writes. If you want to avoid requesting write access too often, you could open the database read-only; then you’d know SQLite would only be reading. When you need to make a change you could open another handle with write access just for that transaction. > Another idea was to copy the db from the file into an in-memory database > using file coordination, make all modifications in-memory and then copy the > in-memory back to the file system. Why not copy it on-disk? iOS 10.3 or later has the APFS filesystem, which is copy-on-write at the block level, making it extremely cheap to copy files. So the initial copy operation will be nearly instant and consume nearly zero disk space, and subsequent changes will use space only for the disk blocks that SQLite changes or adds. Likewise, copying the file back should be instant too. —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
