Here is some better documentation from another SDK (I’ve found some SDK flavors have more detailed documentation on specific topics).
In the “to-many” section example:
const Person = {
name: "Person",
properties: {
name: "string",
birthdate: "date",
dogs: "Dog[]"
}
};
const Dog = {
name: "Dog",
properties: {
name: "string",
age: "int",
breed: "string?"
}
};
Again, this is the object model in the SDK, and your SDK syntax will be a bit different, but you want essentially to use this object model example and translate it to yours.
Regardless of the SDK you use this with, here is the experience you will get:
Each person instance will be in its own collection.
Each dog instance will be in its own collection.
personInstance.dogs will be an array of RealmObjects
personInstance.dogs[n] will be an actual, fully fleshed out data object. You don’t have to manually query them to resolve them from object ids. Also, each realmobject will have an id value in case you want the object id.
You can do things like:
personInstance.dogs[n].name = “new doggie name”
And this will persist back to the instance of the dog in the dogs collection. The person instance in the person collection just contains a reference (that is resolved automatically for you) to the instance in the dog collection.
Also, with flexible sync, you don’t need to pull every person or dog in the collections for this to work. If you use a subscription, you can pass a query/filter/where syntax to pull down just the Person instances (and dogs as applicable) that are relevant. This is what Dachary was referencing:
let config = user.flexibleSyncConfiguration(initialSubscriptions: { subs in
subs.append(QuerySubscription<ItemGroup>(name: "user_groups") {
$0.ownerId == user.id
})
subs.append(QuerySubscription<Item>(name: "user_items") {
$0.ownerId == user.id
})
}
In this example from the swift-ui-tutorial link above, in your case, “user_groups” is Person and “user_items” is dogs. You need a subscription to each collection, and can filter down to some more limited dataset as appropriate. “ownerId” would have been set up as a “queryable” field.
Make sure you have set permissions properly on the server’s collection permissions and not just filtering in the end client interface.
Again, check out some subscription articles from various SDKs to get a more complete understanding of how subscriptions are handled.
I was able to track down this documentation, so I think this is more helpful than my implementation as it will allow you to discover more answers to questions around these topics. I basically did what is above where I have a queryable field by ownerId, and subscriptions to both collections, and then can interact with the data objects without having to manually resolve the references.
Hope this helps!