@Shi_Miya So one thought I’ve had about implementing this is -
A common realm which includes a list of all Articles. The ArticlesList View would contain a model of all Articles which has some denormalized data about the User, for instance their display name and description.
Then a user would click on an article which would navigate to a view just for that article (and bound to a query just for that Article id) - no need to modify the data model here.
Now for the trickier bit - your UserInfo page - at this point you’ll likely want to switch to a per-user realm. The user who is requesting another user’s realm will need to request the appropriate partitionKey value in order to open that realm - once they open that realm they will have read permissions for that realm and can view the users data (or as much as you want to allow, you may want to split “private” user data into another realm. )
// Common Realm
class Article: Object {
@objc dynamic var name = ""
@objc dynamic var body = ""
//this is where you put the partitionKeyValue the user object in the per-user realm
@objc dynamic var userRealmPartitionKeyValue = ""
}
From here you would then open the user realm for this user by passing this field into a new realm open call. Such as (pseudocode for the sake of understanding)
let realm = try! Realm(configuration: user.configuration(partitionValue: myArticle.userRealmPartitionKeyValue!))
I hope this helps. We understand that managing different realms can become a bit of an implementation detail and we are endeavoring to fix this. It is our top priority right now to implement a flexible syncing model - a la query-based sync in the legacy realm cloud which would make this schema design much easier.
@Jay I appreciate your response here and it hasn’t gone unnoticed, but I think we should direct people away from object-level permissions for the legacy realm cloud. It was a good idea but it didn’t scale and right now per-realm/partition permissions is what we have. Stay tuned for future “flexible-sync” improvements