将 MongoDB Atlas 数据划分为 Realms

Question

I am working through partitioning of MongoDB Atlas data into Realms to use the Realm sync feature for mobile devices. For reference, I am looking at the information provided here:

https://docs.mongodb.com/realm/sync/partitioning/#partitioning

When sharing data between users, MongoDB proposes the following partition strategy:

User Realms: If your application stores data privately for each individual user, you could create an owner_id field containing a specific user ID for every document. Selecting the owner_id field as your partition key would partition your database into realms corresponding to individual users.

Team Realms: If your application shares resources across teams, you could create a teams collection that maps user IDs to team IDs. You could then create a team_id field containing a specific team ID for every document you want to sync. Selecting the team_id field as your partition key would partition your database into realms containing data for entire teams.

Public Realms: It's often helpful to store read-only data viewable to all users; for this kind of use case, you can define a special partition value in your permissions, such as PUBLIC, that all users sync with read permissions only.

So that all makes sense, but what about documents that a user creates and then shares with one or more other users? If I have a sharedWith field that points to other user_id's , and I make that the partition key, then it could work but all the documentation seems to caution against updating the value of these partition keys for risk of triggering a client reset.

Through the research I've done via google, StackOverflow etc., I can only find examples that assume the data stays static but I need to allow users to add and remove the sharing permissions. Any suggestions on how this might be approached?

Answer 1

I don't use Realm but looking at that documentation I'd say for documents you would use the public partitioning with document id as the prefix, similarly to how salespeople are handled.

Then I imagine you'd need to have a server-side endpoint for sharing which would write permitted document ids into all of the users that have access to those documents (the server-side endpoint will be able to see the complete view of data, not limited to any one user).