, free & fully virtual. Register Now, free & fully virtual. Register Now

Help with MongoDB Realm partitioning strategy

Hi. I have a scenario that appears to me as a poor fit for Realm sync, but I’d appreciate the thoughts and advice of others in case I’ve overlooked something.

Here is the scenario, simplified as best I can:

Logical entities
Site->Job->Job details(outputs logged to each worker) + workers/users etc

4 Roles
Employee-Admin (read/write access to all jobs and work details - creates jobs and assigns staff)
Employee-Senior (read/write access to assigned jobs)
Employee-Junior (read access to just the work details they performed)
Site Manager (external to org - read access to all work details for each job performed at their site)

Additional info
Data entry during a job could be messy. A senior employee could add job details for themselves and 3 junior employees, whilst an employee with the admin role could add job details for themselves plus a junior employee. Jobs may only last a few days before the workers move to another site. They rotate through sites, meaning the concept of a site is sufficiently independent of a job, and many sites have no internet availability where the work is conducted and data entry performed.

From what I’ve learnt of Realm sync so far, it would seem that client-side filtering may be easiest for internal staff (where cross-role security might not be much of an issue and there are very few data writers), whereas external staff might need a different Realm App using a different partition key, or a duplicated set of records with a partition value set just for them. As these sound like nasty compromises I’m hoping someone has better ideas than me as to how to tackle this scenario.

@Jared_Homes Sounds like you’ve done some research already. Our initial implementation with partition based sync makes it a bit more difficult to allow the kind of hierarchy of roles and the sharing of data that you described but we are currently putting a plan together to allow for more flexible syncing in the future.

However there is a solution you could implement today to solve this as long as you are okay with denormalizing and duplicating the data. You can create a per-user partition and then copy shared job documents between users that have access. You can use Atlas database triggers to observe changes occurring on one user’s partition and copy to all other user’s who also have access to that same job document -

@Ian_Ward Thanks for triggers tip. I’ll keep that in mind, however in my scenario I’d anticipate 99% of the records in the database being low level job details with each document needing to sync to 4-5 users on average. Most of the database would then consist of heavily duplicated data…

+1 vote for more flexible syncing (or a query-based sync) in the near future. And more .Net love with code samples etc. Thanks.