Expose a Obj::get_parent API

[nirinchev]

Seems like internally, we can get an embedded object's parent via get_all_backlinks, but there's no API to do it, other than very inefficiently getting the path, then trying to traverse it until the first top-level object.

[sipersso]

Not sure if this is the same problem, but I think one of the comments I made here https://github.com/realm/realm-cocoa/issues/7145#issuecomment-834192715 is very relevant for this.

Without the ability to check backlinks during migrations it is pretty much impossible to migrate a list of realm objects to a list of embedded objects.

The enumeration approach suggested here https://github.com/realm/realm-cocoa/issues/7145#issuecomment-827029259 does not really work in real world scenarios. I tested this approach to migrate a typically users data (2MB of data) and the migration took 5 minutes to run when all I need to do is to remove orphaned objects that you seem to be able to easily detect once the migration block has completed.

[nirinchev]

@ianpward @fealebenpae can we bump the priority of this? It's been almost a year since we decided to "do it shortly after the launch of embedded objects".

[papafe]

@ianpward @nirinchev Can we bump this? We just had another request for this functionality, and unfortunately backlinks don't solve all the needs

[nirinchev]

@jsflax @ianpward can someone on the core team pick this up please?

[ianpward]

@bmunkholm is this on the quick wins list?

[bmunkholm]

@ianpward Yavor is assigned now.

[sync-by-unito[bot]]

➤ Nikola Irinchev commented:

[[email protected]] is this really in progress? Should we move it to the backlog in order to prioritize it at the next Core planning? Seems like a good intro task for a new hire/new grad.

[nirinchev]

@nicola-cab was this closed by accident? I'm not sure the linked PR addresses the parent API.

[nicola-cab]

No, it is wanted. Why do you need to get all the backlinks? Why don't you try to let core handle that, instructing core with the new configuration? Especially because the algorithm for migrating tables from top to embedded is quite complicated, surely not something to write in the SDK. Besides, a schema violation exception will be thrown way before to be able to react in the migration callback and be able to transform all the objects..

[nirinchev]

This request is not related to migrations - it's a convenience API for obtaining the parent of an embedded object. It was part of the scope/design of EmbeddedObjects but was not implemented due to lack of time.

[nicola-cab]

OK, then reopen it, but why do you need such API? For checking if the embedded object has a parent? for checking if the migration would succeed? All this is now handled in core..

[nirinchev]

No, it's needed to be able to delete an embedded object (among other reasons that I have forgotten since it was 2 years ago). Since we decided to disallow direct deletion of embedded objects (e.g. realm.Remove(myEmbeddedObject)), we figured we should expose an API to get the parent and use that to delete the object - (myEmbeddedObject.Parent as SomeParent).Child = null.

Additionally, it is useful since embedded objects can be contained in multiple parent types and enumerating all of them with the SDK backlinks syntax would be annoying. This is because backlinks exposed in the SDKs are typed, so you'll need to do something like:

var parent = myEmbeddedObject.GetBacklinks<ParentType1>("Child").FirstOrDefault()
    ?? myEmbeddedObject.GetBacklink<ParentType2>("Child").FirstOrDefault()
    ?? ...

[ironage]

@nirinchev we have Obj::get_path() and Obj::get_fat_path() which return the entire path to an embedded object, the top object will be the first element in the returned list. Does this satisfy the need here or do you want something else?

[jedelbo]

@ironage I just made support for this