Provide a utility that allows easier parsing of ObjectIds when they're returned to the client. As it stands, ObjectIds are returned as UInt8Arrays and cannot be readily used in the BSON.ObjectId constructor. Being able to retrieve specific items by ObjectId is necessary and the only way to do this dynamically (without knowing the hex string beforehand) is to retrieve the items and then use the returned id; however, as it stands, using the returned id is obfuscated and impractical.

I am now having to use the following workaround:

const toHexString = (bytes) =>
bytes.reduce((str, byte) => str + byte.toString(16).padStart(2, "0"), "");

client.find({_id: new BSON.ObjectId(toHexString(arr: Uint8Array)})

It would be great if revision history could be kept, either on individual RealmObjects, groups of RealmObjects, or the Realm as a whole. There could be a way to specify the fidelity of the revisions (e.g. every change or every X minutes) and a way to specify a TTL (e.g. last 30 days). If the Realm is synced, the local Realm could purge its cache of revisions older than the TTL and there could be an API to retrieve these when needed. Additionally, there could a (separate) TTL for permanent deletion of revisions as to keep the Realm from growing too large. Or, alternatively, a way to move revisions to cold storage.

A basic use case for this is editing a document and being able to view a revision history of the document and restore a previous revision. A document could be represented by a single RealmObject that contains several RealmObject and RealmList fields, so I imagine there would need to be a way to have the parent document RealmObject have a reference to a revision anytime any of its child RealmObjects change (of course, based on the fidelity).

Please have the SDKs allow to copy objects from one partition to another. Currently you have to manually do it, which isn't great but not horrible, until your object has nested Objects, List<>s or EmbeddedObjects (via referenced 'foreign_key' / _id) - that is when it gets nasty and cumbersome. In Legacy Realm when ever you copied a top-level object its nested Objects & List<>s were copied automatically. That is not the case anymore, in MongoDB's Realm each one has to be done manually.

Built-in deep copying Objects is further important since:
1) Using partition-based Realm leads to denormalizing your data, which means more copies (not horribly bad if a new object but if existing one then harder).
2) Another reason why you need to denormalize your data is that Sync Permissions are determined at the partition-level, and not at the document level. It would have been nice to be able to use the ‘%%root’ as a JSON expression in Sync Permissions (and process are document level) to gain access to each document (aka: object) being processed - in order to allow / restrictions read or write permissions.

Using Realm with reactive extensions, 3rd party libraries like DynamicData, and UI binding allows one to create beautifully dynamic, responsive apps with very few lines of clean code. This works fantastically for us in all scenarios except for when an item is deleted.

As we all know, currently any attempt to access an item's properties after deletion throws an exception. This throws a huge spanner in the works for various reactive operations and UI bindings, which may (for implementation detail purposes of object equality checks, UI redraws queued in the event loop queue, or a bunch of other possibilities) still briefly try to read the properties of an object after deletion. Even sometimes just to remove it from an internal cache somewhere along the reactive processing chain when processing the deletion itself.

As a result we have to constantly walk on eggshells in our code, put in lots of additional checks and filters and ugly hacks like flagging objects as deleted but not actually deleting them, or copying Realm object properties to keep them available, etc., just to try to avoid random app crashes that otherwise occur (since you can't catch these exceptions in any meaningful way when they occur in the middle of a reactive processing pipeline on the UI thread). And to date we have been far from totally successful.

All this code ugliness and app brittleness could be avoided if Realm object properties could still be read after detaching. It could be opt-in, either on a per-object basis (e.g. there could be an overridable 'AllowDetachedRead' property or similar) or at the Realm level as part of config.

Another way to offer this would be an optional 'AutoFreezeOnDetach' feature that automatically freezes the object in place when it is removed from the Realm. I tried doing this using existing functionality by calling FreezeInPlace() when the object becomes invalid, but that threw a native exception deep within the bowels of Realm. Not entirely surprised since by that point the object has already been deleted.

So, can we have an option like this please? It would make life so much simpler and cleaner.