In our .NET app (Xamarin iOS + Android), we are getting a notification about a change to the parent object when only a single child object has changed. The relationship between parent and child is one-to-many. We’re looking for a way to avoid getting those notifications. The parent object contains a List of child objects like this - see snippet below. When a ShowroomPhoto changes, we get a notification about the changed parent object. Both parent and child objects subclass RealmObject.
[MapTo("photos")]
[Realms.Preserve]
[WovenProperty]
public IList<ShowroomPhoto> Photos
{
get
{
if (this.\u003CPhotos\u003Ek__BackingField == null)
this.\u003CPhotos\u003Ek__BackingField = this.GetListValue<ShowroomPhoto>("photos");
return this.\u003CPhotos\u003Ek__BackingField;
}
}
After some research, it looks like keypath filtering might be one way to solve the issue for us. However, this feature seems to be only available in your Swift SDK, but not in the .NET SDK that we are using:
Providing example code will take a bit of effort, but we’re not doing anything unusual on the front-end.
The parent object is ShowroomVisit, so we query for those:
var queryableShowroomVisits = userDataSource.All<ShowroomVisit>().Where(x => x.MarketId == brand.MarketId && x.ExhibitorCoreBrandId == brand.ExhibitorCoreBrandId).OrderByDescending(x => x.Timestamp);
var subscription = queryableShowroomVisits.SubscribeForNotifications( updatedValues, changes, error =>
{
Debug.WriteLine("got a notification");
});
Okay, so this is expected when using the SubscribeForNotifications API. Indeed, keypath filtering would allow you to customize the behavior, but there are no immediate plans to work on that for the .NET SDK. Are you interested in changes only in the collection or also in the objects inside the collection? I.e. do you care that ShowroomVisit changed if the collection itself was unchanged?
Sorry, I don’t understand your question… We only want to receive a notification when:
elements in the parent collection are added (ChangeSet.InsertedIndices)
elements in the parent collection are deleted (ChangeSet.DeletedIndices)
properties of elements in the parent collection are changed (ChangeSet.ModifiedIndices and ChangeSet.NewModifiedIndices)
the order of elements in the parent collection changes (ChangeSet.Moves property)
all of the elements in the parent collection are cleared (ChangeSet.IsCleared property)
The only time we want to receive a notification about child collection objects is when a child object is added/removed to/from the parent. This would be my expectation for default behavior because the parent internally stores a collection of child ID’s, right?
I see. Unfortunately, this is not something that is currently supported by the .NET SDK. I was asking about what information you need from the change event because the CollectionChanged API is an alternative to the SubscribeForNotifications one and the former only notifies for changes of the collection and not the objects themselves, but it appears that won’t work for you.
I understand your point about the default being listening for top-level property modifications only - it is intuitive to an extend, but it’s different from the feedback we’ve received early on when developing the product. The main driver for the notifications feature was displaying items in a collection view and updating the UI in response to data changes. Each cell in the collection view might be displaying arbitrary graph of references from the top level object (e.g. a listview showing schools might want to display the address or the first/last name of the dean), which is why early adopters of the database were asking for deep change tracking.
Unfortunately, we don’t plan to change the default and as I said there are no immediate plans to add support for keypath filtering. If you’re using Atlas Device Sync and this feature is critical for going into production with your app, you should reach out to your account executive and provide them with timeframes for when you need it and more information about the use case. They will then work with product and engineering to either find a workaround or reorder the backlog to prioritize keypath filtering support higher.
Because the nature of Realm is to fire events when properties change, or when related object properties change, you could get around having events fire by not relating objects (by reference) but instead just store their primaryKey. It’s very un-relational but can work.
class Dog {
primaryKey: 1234
}
class Person {
primaryKey: abcd
dogList: 1234, 5678 etc
}
Another option is keep the Persons primary key as a property of the Dog class
class Dog {
primaryKey: 1234
personKey: abcd
}
then you can add observers Dog and when an event Fires due to a change you’ll know what person that Dog belongs to.
My alternative is to write client-side code to filter subscriptions, so I have to ask again: Is there a timeline to release keypath filtering for the .NET SDK?
This is a super good request and really should be on the radar - perhaps adding a note onto the git linked above would be a good idea.
However, based on what’s shown on that git as well as what was said above, I don’t think there is a timeline so probably best to search for alternatives for now.
