I’m setting up mongoDb realm sync using DotNet SDK. Have setup realm sync with:
Partition key ( _partition ) is set as not required in the sync setup.
Read permission : true
Write permission: based on user Id ( _partition )
On the client side, the realm is opened based on the user Id i.e.
user = await app.LogInAsync(Credentials.Anonymous());
config = new PartitionSyncConfiguration(user.Id, user);
I have 2 collections:
e.g. Task and ProjectSettings
Task collection has _partition that’s set to the userId and syncs with the local realm. The user is only able to see their own data.
ProjectSettings contains settings that apply to all users.
How would I setup ProjectSettings collection to sync on the client side irrespective of the partition key?
From other topics posted here I gathered it can be implemented by setting the _partition value to “Public”.
On the client side, setup a 2nd realm with this key.
Is there a better way to handle this scenario? Is my understanding incorrect that having Read permission : true should sync all data irrespective of _partition?
Or is this limited because the client side realm is being created with the userId as the parameter?
config = new PartitionSyncConfiguration(user.Id, user);
This would allow any user to have access to that data. They type of right read/write permission are then set by you on that partition. As I explain in the next point.
Is my understanding incorrect that having Read permission : true should sync all data irrespective of _partition? Or is this limited because the client side realm is being created with the userId as the parameter?
What you’re referring to is called Global Permission. If you set that to true then all users have the given access permissions for all partitions. But in your case you may instead want to use permissions for each partition
In this way permissions would be relative to the “PUBLIC” partition. This gives you the granularity that you need on that specific partition.
The sync rules that you set apply equally to all objects in that partition only. If a user has read or write permission for a given partition then they can read or modify all synced fields of any object in that partition.
Is there a better way to handle this scenario?
You can’t have only 1 realm for 2 partitions. It’s always 1 realm per partition.
Additionally, if you’d like to dig deeper in other sync strategies you could look at our resources here and here.
Thank you @Andrea_Catalini. I have a follow up question if you don’t mind.
What you’re referring to is called Global Permission. If you set that to true then all users have the given access permissions for all partitions. But in your case you may instead want to use permissions for each partition
In my realm sync settings under define permissions, Read is set to true (global permission). Shouldn’t all the data be available in the collection to all users (regardless of userId) in this case? I only see data from a single user. Is this because of specifying a UserId when creating a realm in my code?
config = new PartitionSyncConfiguration(user.Id, user);
You’re still trying to access all data from one realm. This is not possible. config = new PartitionSyncConfiguration(user.Id, user); gives you the partition user.Id, which is separated from PUBLIC.
With Global permissions you set the same read/write rules for all partitions. But you need to open the right partition to access its content.
One more thing worth mentioning here, we have just launched Flexible Sync. This new feature may come in handy for what you are trying to achieve. In a pinch, this feature allows you to create a realm that doesn’t reflect a partition but rather the output of a client query (possibly a complex one made up of many sub-queries).
This feature is currently available only on the dedicated clusters, at the moment. However, there are plans to release it “soon” on the shared clusters too.
You can have a brief overview of the flexible sync feature in our launch blog-post.
Thank you. I was misunderstanding the concept of a partition and realm. Your inputs helped greatly.
This feature is currently available only on the dedicated clusters, at the moment. However, there are plans to release it “soon” on the shared clusters too.
This would be great for my needs. Can’t wait to try it out once its available on shared clusters.