On 24 Oct 2017, at 4:14pm, Arno Gramatke <ar...@meyersound.com> wrote:
> These single files should be placed in the app’s „Documents“ folder, making > them accessible from other apps or the Files.app when allowed by the user. > With the single db file from above it was only ever our app to access this > file and we wouldn’t have to worry about other processes trying to copy, > move, delete the file. Now with the files stored in the „Documents“ folder > this has changed and we can’t tell when another process tries to access the > db files. For this Apple recommends using file coordination where each read > or write is coordinated through an NSFileCoordinator. > > Has anybody have experience how to approach this? As you’ve already figured out, there’s no easy way to encapsulate SQLite effects within NSFileCoordinator. To do it properly you’d have to write your own library or your own VFS which does both things. Neither of these things are easy and, unless you have most of your revenue from your iOS app, I don’t think either of them are work the effort of writing and debugging. > 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. Then coordinate a read > or write depending on the statement. For example, an INSERT statement will > result in a write to the file (I guess). A SELECT might result in a read (I > am not sure, there might some data already being cached?). It seems that > processing each statement inside a coordinated read or write would lead to a > lot of overhead and I guess this is not what the file coordination was made > for. It rather looks like this was meant for infrequent writes to file or > even file operations where the whole would be read or written in one go. The internals of SQLite are a lot more complicated than this. Not only do you have to worry about the constant reading and writing of journal files, an INSERT can require a lot of reading (to figure out UNIQUEness requirementts) and a SELECT can require a lot of writing (if SQLite has to make up a temporary index). You would have to learn a lot about SQLite internals. > 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. This might be workable. Another alternative would be to keep the real SQLite database files in the App’s sandbox, as you have been doing all along, and to duplicate needed information into the shared areas when the App is backgrounded or quit, or when it is finished with the data for a single 'document'. Do not forget that any user can delete anything in the shared space with a few accidental touches. If your App keeps its only copy of its data in there, users can delete the App’s data by accident, and you will then receive a support call asking why the App has lost all its data. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
