Flexible Sync Must Traverse Relationships

[bdkjones]

Problem

Flexible Sync currently does not support subscriptions based on relationships. All of the examples offer contrived data models, like this:

class child: Object
{
    @Persisted var owner: String = “Bob”
}

The flexible sync examples subscribe to all child objects where owner is “Bob”. But in a real application, owner is likely to be a reference to another object that has a children property. And in that case, you can’t use Flexible Sync to subscribe to all child objects of a particular owner.

(Imagine a Mac app with a list of Owner objects in a master view. The user selects one, then we show all the child objects associated with the selected owner in a detail view.)

I end up telling Realm to just sync all child objects that exist, which entirely defeats the purpose of Flexible Sync and makes using it just a much more cumbersome, verbose version of the old Partition-Based sync.

Solution

Flexible Sync must support subscriptions based on relationships between objects: “sync all ‘foo’ objects whose parent is ‘[some object]’.

Alternatives

Make it easier for me to just tell Flexible Sync I want EVERYTHING synced. So I don’t have to write 18 lines of “subscriptions”.

How important is this improvement for you?

Would be a major improvement

Feature would mainly be used with

Atlas Device Sync

[nirinchev]

This is a fair feedback. Unfortunately, it's not something that is feasible to support in a performant way with how MongoDB works - when we setup subscriptions, we need to be able to evaluate whether an object matches the subscription query only based on the information contained within the object. It would be prohibitively expensive to re-run all queries for every object change, which is what would be required if we would support "proper" traversing of relationships in queries.

That being said, it does seem like your use case is not about traversing a relationship but rather matching on one - i.e. parent == *some_parent*. This is something that we could feasibly support as the object link is represented with the id of the target object on the server and we do have it on our todo list, even if we can't give timeframes for when it'll be available.

[nirinchev]

As a workaround, you could denormalize your data (I know, not a huge fan of it either!) and store the parent id in another field on the object and write a query like sync all ‘foo’ objects whose parent_id is ‘[some object]._id’.