Sanity check: Subscriptions based on the ID of a linked object are not supported

MongoDB Atlas App Services & Realm Realm
1

In my application a user can create Activities, which for the sake of simplicity just have a name, an id, and a creator, where the creator field is a linked object in the PublicUser collection. I’m using @realm/react and typescript, so the model looks like this:

export class Activity extends Realm.Object<Activity> {
  _id: Realm.BSON.ObjectId = new Realm.BSON.ObjectId()
  name: string = 'Unnamed activity'
  creator!: PublicUser

  static primaryKey = '_id'
  }
}

I would like every user to be subscribed to documents in the Activity collection where they are the creator. However, this seems to be disallowed, as the PublicUser is a linked collection. To set up the subscription, all I need is the ID, which is exactly what is stored in the database itself. But Realm only sees a link, as far as I can tell, and there is no way to use the ID itself when establishing a sync subscription.

To get around this, I can duplicate the ID in a separate field, eg

export class Activity extends Realm.Object<Activity> {
  _id: Realm.BSON.ObjectId = new Realm.BSON.ObjectId()
  name: string = 'Unnamed activity'
  creator!: PublicUser
  creatorId: Realm.BSON.ObjectId

  static primaryKey = '_id'
}

This duplication allows me to establish a subscription on the basis of the creators ID. I plan on using this approach, but I wanted to make sure that I am not missing some way to simply look at the link as an ObjectId rather than a Link, as it would be much cleaner. There are several similar cases in my app so I’d rather avoid the duplication strategy if possible.

Thanks,
Brian

2

Hello @Brian_Luther,

This is actually the same approach I came up with back in 2021, and have used ever since for Realm except for when I use CoreData in which case I sync Realm to CoreData or Room to store the IDs and reference them, and use aggregations and indexes in Atlas to handle things from outside of the clients/reference them and so on.

But you are on track, as I also take the IDs and make them their own associated collection that ties the username to the ID numbers and make other realm apps as separated collections hold the other associated information.

Such as transactions etc. So that way if my app(s) using Realm were ever breached no one attacker would have the whole picture of any one users. Addresses were separated from phone numbers, and SSNs were separated from names and addresses, names were held separately from address and phone numbers and SSNs, their purchase histories were all separate and so on.

So the internal, non-displayed ID is what tied everything together for any one user. This also helped with a CDC audit due to COVID to determine how many and who were at location Y, I could provide the CDC with the exact info requested for my friends app, instead of giving them all of the users info.

It actually made things a lot easier, same goes for his bookkeeping. He’s using a different platform now, but same kind of a setup.

3

Hi @Brian_Luther,

You are correct that this is not currently supported. The workaround you proposed is how we’d recommend doing this for now.