What's the deal with frozen and managed objects?

X_Jia · 2024-07-21T09:03:40.561Z

The documentation says:

the Kotlin SDK does not provide live objects and collections that update simultaneously with underlying data. Instead, the Kotlin SDK works exclusively with frozen objects that can be passed between threads safely

OK, so thread safe!

But from my usage experience, this creates two major co-existing problems that far out weigh the supposed benefit of “thread safe”.

The objects don’t get live updates.
The objects can not be modified.

(Well, you can modify the object in a write block, which get saved to the DB, but then your modifications are not reflected in your existing object)

The two co-existing problems are quite contradictory in logic:

Since the objects are frozen (without any updates from the DB) why the DB maintains that they be “managed”? Why not let them be as ordinary Kotlin objects that can be freely modified?
Since the objects are managed by the DB and can not be modified by the user, then why not give live updates?

The usage of these objects becomes quite awkward, and the issue of “thread-safe” is far less of any concern for me.

Azri · 2024-07-23T04:52:07.464Z

Hi @X_Jia,

Here’s how this document explains the Frozen Architechture:

Frozen by default: All objects are now frozen. Unlike live objects, frozen objects do not automatically update after database writes. You can still access live objects within a write transaction, but passing a live object out of a write transaction freezes the object.

Thread-safety: All realm instances, objects, query results, and collections can now be transferred across threads.

Singleton: You now only need one instance of each realm. No need to open and close realms on individual threads.

There’s a focus on immutability for better control over object state & as you mentioned, allows for thread-safety.
There’s a video and transcription of a meetup that presents the topic at length.