Adds Realm.copyFromRealm()

[cmelchior]

Fixes #931

Adds 4 new methods that makes it possible to make detached deep copies of managed RealmObjects:

RealmObject objectCopy = Realm.copyFromRealm(RealmObject object);
RealmObject objectCopy = Realm.copyFromRealm(RealmObject object, int maxDepth);
List<RealmObject> listCopy = Realm.copyFromRealm(Iterable<RealmObject> objects);
List<RealmObject> listCopy = Realm.copyFromRealm(Iterable<RealmObject> objects, int maxDepth);

As discussed this breaks Realms zero-copy and consistency guarantees, but enables architectural patterns currently not supported by Realm.

[cmelchior]

@realm/java

[saket]

Interesting! How does maxDepth work here?

[zaki50]

this import seems to be unused

[cmelchior]

Ups, will fix

[cmelchior]

It is there to prevent copying to much data. Realm is an Object database so you might construct your data model in such a way that you can access the entire graph. This could be potentially very memory intensive to copy, so being able to break the graph makes this scenario easier to control so you don't run out of memory.

See e.g this unit test: https://github.com/realm/realm-java/pull/1849/files#diff-b11f4583c757aa2c5f52d4fb9e4ac750R2348

[saket]

Looks good. Thank you! I've been cloning into raw-objects manually in my code.

[zaki50]

Current implementation searches and duplicates the object graph by depth-first search.
This causes reconstruction of sub graph if the same object appears more than once and depth is smaller than before.

To avoid this reconstruction, we can use the breadth-first search since the depth monotonically increases.

This is just an optimization and might not be needed at first release.

[cmelchior]

Yes, it is depth first currently. Mostly because it was easier to implement and also because I think this feature will mostly be used on leaf nodes, which means we won't have to repopulate objects often (pure speculation though).

So as far as I can see we have the following trade-offs:

Breath-first

• + Don't have to repopulate cached objects that are encountered at lower depths
• - Will always have to maintain an extra queue that consists of a tuple of (realmObject, standalone) for all references at each depth.

Depth-first:

• + No need for extra datastrutucures = less memory pressure.
• - Will have to repopulate objects encountered at lower depths.

Given that I wouldn't anticipate this being used on either many or deep objects i opted for simplicity, but I'm happy to hear arguments for changing it?

[kneth]

"data" -> "objects"

[beeender]

Nice! 👍

[zaki50]

Depth-first is OK as first release. We should keep simple if possible.
And if we will find the use-case which requires Breath-first, we can introduce Breath-first implementation at any time.

👍

[kneth]

Even though I do have reservations about diverging from the zero-copy principle I think it looks good.

[saket]

Is it possible to start using 0.87 so that I can use this feature?

[cmelchior]

Yes, you can use our SNAPSHOT releases : https://github.com/realm/realm-java#using-snapshots

[saket]

Ah yes, thanks!

[borkasm]

I wonder why this functionality maintained only in Java. Just run into the situation where it would be nice to have it in Swift.

[cmelchior]

The Android and Swift communities have different paradigms, patterns and libraries that are commonly used. So while we strive to have feature parity between Java / Swift / Objective-C there will always be small differences.

If it is a feature you would like implemented I would suggest raising it as an issue for Realm Swift. They already have an issue tracking it here: realm/realm-swift#3381

[borkasm]

Thanks, I think I will find a simple workaround this time.

[zhihuitang]

thanks @cmelchior, nice job

[othreecodes]

Awesome!!!! thank you for this!