EmbeddedObjects seem like a good fit for my current use case as I have a schema something like:
Parent: Object
– [Child: EmbeddedObject]
---- [SubChild: EmbeddedObject]
If I .observe the parent object for changes using a NotificationToken I don’t ever pick up anything that happens when children or sub-children are modified. Any changes that occur directly to properties on the top-level parent object do result in a notification for changes however. Is this expected?
Thanks!
I should add that I’ve also tried to .observe the List that exists on the parent object and that indeed works. I suppose that this is probably a compromise that keeps Realm’s performance from degrading with deeply nested objects.
Having an option to ignore this, ignore it to a certain nested level, or to have nested embedded objects of given types trigger notifications would be useful.
@Mike_McNamara Did you ever find resolution to this problem? We are getting unwanted notifications for child objects, and are looking for ways to silence them… I’m imagining there might be an attribute on the property that could achieve this but haven’t found it yet.
Can you clarify what the ‘problem’ is?
An embedded object is not a child object like you would have when the objects are discreet and have a forward relationship.
An embedded object is just that, embedded, and actually part of the schema of the object and can be thought of as just another direct property of the object. It follows the object; for example, if the object is deleted, all of its embedded objects are deleted as well. If it’s copied, that copy will include all of the embedded objects.
If an object is being observed, you are asking Realm to tell you about any changes to the properties of that object… and if an embedded object is changed within an object, the object is changed so the “modified” event fires.
Is that not what you’re experiencing?
Are you expecting some other behavior? If so, can you tell us a little about what you’re after so perhaps we can point you in the right direction?
Including some code examples may help and consider crafting a separate question if this ‘problem’ isn’t actually what you’re asking about.
Solutions would include changing your observer to be more granular with, for example, key-path observing of objects instead of object or collection observing.
Hi, @Jay. This topic opened by @Mike_McNamara seemed similar to what we were seeing, but upon further research, probably not. Let me explain…
In our .NET app (Xamarin iOS + Android), we are getting a notification about a change to the parent object when only a child object has changed. The relationship between parent and child is one-to-many. This is unexpected behavior, and 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.
[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:
Add support for keypath filtering for notifications · Issue #1398 · realm/realm-dotnet (github.com)
I assume Photos are Embedded objects.
If so, that’s actually expected behavior when it comes to Embedded Objects, but not when it comes to Objects.
Realm enforces unique ownership constraints that treat each embedded object as nested data inside of a single, specific parent object. An embedded object inherits the lifecycle of its parent object and cannot exist as an independent Realm object. Realm automatically deletes embedded objects if their parent object is deleted or when overwritten by a new embedded object instance.
That’s also the reason that cannot be directly queried - they can only be queried though the parent object.
So while an embedded object ‘feels’ like it has a relationship to its parent, it is really just a property of the parent and reacts like any other property would in regard to firing events upon modification. Which is why I mentioned the behavior is expected.
I (now) see you are using .Net so a more granular solution like key-value observing (as in Swift) is not available so another possibility is to store them as managed Realm Objects instead of Embedded Objects - that will give you the behavior you’re seeking as changes to those objects would not fire an event for an related object.
Actually, both the parent object (ShowroomVisit) and the child object (ShowroomPhoto) subclass RealmObject - not EmbeddedObject.
lol. Let’s start again!
The title of the initial question and the question itself revolve around EmbeddedObjects.
If you’re not using EmbeddedObjects then please open a separate question as all of the above info will not have any relevance to your question.
Do that and we’ll take a look!
Ok, thanks. I created a new ticket:
Unwanted notifications about changed objects in child collection - MongoDB Atlas App Services & Realm - MongoDB Developer Community Forums