Hi @Dominik_Koller - welcome to the community!
Sorry about the problems with the SwiftUI Quick Start. You’re right, we’re missing some information about setup and that’s what’s causing your issue. You’ll need to update your Sync configuration to get going with the quick start. Head into your Realm App in the web UI, and choose Sync in the sidebar to update your Sync configuration.
Before you can enter a partition key, you’ll need to specify a cluster and database. To verify the Quick Start is working as expected, I used the default cluster in my project, and created a database named SwiftUIQuickStart. You can create a new database or use an existing one. When you start syncing data, Development Mode will automatically create collections for each object type you sync, which in our case will be Group and Item, the two objects in the SwiftUI QuickStart.
When you configure Partition-Based Sync in your Realm Application, you must specify a partition field. I actually didn’t think you could enable Partition-Based Sync without one, so if you were able to successfully enable Sync, that might be a bug in the UI.
Your partition key is a field in your schema, but Development Mode lets you enter a partition key without having a pre-defined schema (among other things). For the SwiftUI Quick Start, go ahead and use _partition
as a partition key - it’s the default name that we tend to use as a synthetic partition field when the object models don’t have a natural partition key.
For Permissions, I used a template: User can only read and write their own data. If you want to just paste in the code, those permissions look like this for both Read and Write:
{
"%%partition": "%%user.id"
}
Once you have Enabled Sync with those settings, and have deployed the updated application configuration, the client should “just work.”
Aside from those missing setup details, the part that we’re not explaining very well in the client application code is how we’re using the partition value.
In the SyncContentView
, we check for a logged-in user, and pass that user’s ID as the partitionValue
to the next view down the hierarchy using an environment object:
OpenSyncedRealmView().environment(\.partitionValue, user.id)
In the OpenSyncedRealmView, we are using that partition value in the @AsyncOpen
property wrapper:
@AsyncOpen(appId: YOUR_REALM_APP_ID_HERE, partitionValue: "", timeout: 4000) var asyncOpen
The empty string using the passed-in partitionValue
from the environment object is a bit of magic that the property wrapper is doing under the hood.
This line means we’re opening a synced Realm with the user.id
of the current logged-in user.
When you see the main UI, there are no items in the view. That’s because we’re using anonymous login, and there won’t be any objects matching this user’s partitionValue - i.e. their user id. When you start creating objects, those objects write to Realm - both on the device, and in the linked database you specified in the Sync configuration. The realm file itself has the partitionValue. The objects that the user writes to the realm file have that partitionValue appended as the partition field you specified in the configuration. If you go look in the linked database, you’ll see both the Group objects and the Item objects contain a field _partition
that contains the user ID of the logged-in user who created the objects:
And you’ll see in the Schema that Development Mode has inferred, you now have a _partition
in the schema:
{
"title": "Group",
"bsonType": "object",
"required": [
"_id",
"_partition"
],
"properties": {
"_id": {
"bsonType": "objectId"
},
"_partition": {
"bsonType": "string"
},
"items": {
"bsonType": "array",
"items": {
"bsonType": "objectId"
}
}
}
}
Even though you haven’t defined it explicitly in the object model.
You can experiment with different partition values and permissions to get a feel for how partitioning works in Realm.
Hope this additional info helps you get going with the SwiftUI Quick Start. I’m putting in a ticket to update this documentation to offer more complete set up steps, and provide more info about how partitionValue works in this context. If you still have questions, let us know!