Multiple values of partitionKey

MongoDB Atlas App Services & Realm Atlas Device Sync
1

Hi All

I am working on a react native application with Realm Sync. I have a scenario where the partitionkey value in the collection is all different. 61 documents and 61 values of partition key. I only have to sync 5-10 documents in client application based on partitionkey value . As per the docs, only 1 partition key value can set in config to sync that specific data:

const config = {
   schema: [MySchema],
   sync: {
     user: user,
     partitionValue: partitionValue,
   },
 };

Can someone help me in understanding how to send multiple partitionValue. If it is not possible what is the other way of doing such sync.

2

I have the exact same question!

3

@Saba_Siddiqui You can only open a realm with a single partitionKey value - however, you can open multiple realms in your client side app - each with a different partitionKey value

4

@Ian_Ward: I have an “order” collection where document is like :

 {
    _id:"order1",
    _partition:"merchant=MER1",
    merchantId: "MER1",
    customer: {name:"CUST1",  phone:1234},
    price:100,
    items:[......]
 }

I want this document to available on the customer device(CUST1) and merchant device (MER1).

The current partition value creates a realm for all Orders belonging to a merchant, but I still don’t understand how to keep the order placed by a customer in sync on their devices. Please suggest.

1 Like
5

I have a similar question but I think we need more clarity on the use case. For this specific question one obvious solution is to open a realm on both the client and merchant devices using the partition “merchant=MER1”. However, the downside is that every client (I assume there’s more than one) has access to all other clients orders.

Can we assume that each client should only be able to see their own orders and the merchant should be able to all clients orders?

6

@Jay
Can we assume that each client should only be able to see their own orders and the merchant should be able to all client’s orders?

So the requirement is that all the customers should see the orders placed by them and all the merchants should have the orders received by them from different customers.

If I follow the current approach of partitioning “merchant=MER1”, then the realm on the customer device would also get the other orders not placed by him.

7

I just wrote an article on Medium about how to implement multiple partition key values for a chat program on MongoDB Realm. All of the code is open source; feel free to download and experiment. We are in the process of writing a React-Native version of this as well.

4 Likes
8

That ‘chat use-case’ is only fulfilling the 1 to 1 scenario. But when, for example, a merchant wants to sync ALL his orders and a customer should ONLY see his orders it won’t work, or am I wrong?

(And we don’t want to open 1 realm for each order)

Let’s consider the partition keys would be like "merchantID_customerID":

  • The customers should see all realms that contain the ‘customerID’
  • The merchants should see all realms that contain the ‘merchantID’

Would be kind of using wildcards in partition values when opening a realm… is that possible?

Or maybe there is another way to solve this? :thinking:

1 Like
9

Ebrima,

So first off, there is no wildcard capability in Realm partition values. You basically open a Realm with a specific partition key value, and read/write to it. But your instincts are correct, you probably want to organize your partitions as merchantID_customerID - where both a merchant and a customer have read/write permissions on this partition key value. Use the technique involve custom user data and sync partitions that I outlined in the paper to accomplish this. The downside with this architecture is that a merchant client will have to open all the realms for its customers, and a customer client will have to open all the realms for its merchants. This list of merchants and customers can probably be kept in the user realms for each merchant and customer respectively.

I hope this was useful.

1 Like