Context
I'm using https://github.com/stephencelis/SQLite.swift as the access layer for interacting with SQLite databases.
For each database I maintain a long running connection. As reading the schema is done lazily on each connection and can be expensive I prefer to open the connection once, do a number of operations and then close the connection when it is not needed any more (and given that the app is a GUI for working with SQLite databases, long running means long running).
E.g.
func open(url: URL, options: ...)
func commitCurrentTransaction() throws
func rollbackCurrentTransaction() throws
func executeStatements(rawSQL: RawSQL, executeMode: ExecuteMode) async throws -> SQLOperationResult
...
func close()
To be a good citizen on the Mac I'm looking to use the NSFileCoordinator to indicate read and write operations on the SQLite database files the application is using.
I'm thinking of wrapping each operation that might result in a file access with the corresponding coordinate(readingItemAt: ... and coordinate(writingItemAt: ... calls.
But the API documentation states that the last argument, the block byAccessor should use the given URL:
A Block object containing the file operations you want to perform in a coordinated manner. This block receives an NSURL object containing the URL of the item and returns no value. Always use the URL passed into the block instead of the value in the url parameter.
In my case, the URL is used once when opening the connection but not afterwards so I'd be ignoring the URL passed to the block.
The examples I have found for using the NSFileCoordinator seem to follow a different pattern, where the entire operation on the file happens within the block of the coordinate method.
Questions
What is the correct way of using NSFileCoordinator in a case like this where there essentially is a long live file handle in use?
The application does work without using the NSFileCoordinator. What is the ramification of not using the NSFileCoordinator in this case?