Multiprocess Support
It supports that too.
YapDatabase supports sharing the same database file across multiple processes. This is commonly used for tasks such as creating iOS App Extensions. However, there are certain limitations you must be aware of.
There are 2 steps to perform to get multiprocess support up-and-running for YapDatabase.
First, YapDatabaseOptions has a property named enableMultiProcessSupport. You'll need to turn this on for each YapDatabase instance that will be using a shared database file. This applies to every process.
For example:
Let's say you have a primary iOS app which uses 2 different YapDatabase instances:
- A: "main" : The main database file which will be shared with the app extension.
- B: "cache" : A database file used by a utility class for caching some stuff. Not shared.
And the app extension, which uses 1 YapDatabase instance:
- C: "main" : The main database file which is shared with the primary app.
You must set enableMultiProcessSupport to true for A & C. (It's not necessary for B, because the corresponding database file isn't being shared between multiple processes.)
Second, you MUST use the exact same set of extensions for each YapDatabase instance sharing a database file.
In the example above, this means that the YapDatabase instance for A & C MUST register the same set of extensions, with each extension configured the same way. What this means in practice is that you should share a single source file between the two applications that's responsible for setting up and configuring the database. (E.g. a shared DatabaseManager source file).
This is critical, as database extensions (such as YapDatabaseView) take part in the atomic read-write transaction, and rely on the ability to modify their own internal sqlite tables.
For example, let's assume our app extension code violates this rule, and configures the YapDatabase instance for C without matching a YapDatabaseView that's created for A. The app extension then performs a read-write transaction, and modifies an object in the database. Since the transaction took place in the app extension process, the YapDatabaseView (which is primary process only) won't see the change, and thus its tables may be out-of-sync. (E.g. the modified object should no longer be in the view, but it still is.)
If your app extension accesses the database in a read-only fashion, then you can violate this rule. (But you should still be aware of it, and should likely enforce the read-only restriction via YapDatabaseConnection. permittedTransactions.)
Non-persistent YapDatabaseView's may not be an option. Again, this is only a restriction if multiple processes are modifying the database. If only a single process modifies the database, then that process (and only that process) can safely use non-persistent views.
If multiple processes may be modifying the database, you'll likely want to setup the YapDatabaseCrossProcessNotification extension. This extension allows you to be notified when the database has been updated in another process. It will then post a YapDatabaseModifiedExternallyNotification to the main thread.
You should treat this notification similar to a YapDatabaseModifiedNotification. E.g. you'd invoke [databaseConnection beginLongLivedReadTransaction] in order to jump to the latest commit in the database.