`RealmDictionary` feature #1239

edualonso · 2023-01-25T14:25:31Z

Closes #537

Dictionary API

A RealmDictionary is a Map<K, V>, where keys are always strings and values are Realm primitives or objects, be it regular or embedded. Dictionaries can also be expressed as:

MutableSet<MutableMap.MutableEntry<K, V>> by calling RealmDictionary.entries. The entry set is a live collection connected to its underlying dictionary. Deletions and insertions are allowed and will result in an updated dictionary. Individual entries can also be modified and will result in an update key-value dictionary pair. Unmanaged entries can also be instantiated via factory - see "Factories" section below. Managed entries are also live key-value pairs and mutating them will update the dictionary accordingly.
MutableSet<K> by calling RealmDictionary.keys. The key set is a live collection connected to its underlying dictionary. Deletions are allowed though insertions aren't - it isn't possible to insert a key without a value. Core delivers the keys as realm_results_t but subscribing for key changes is not exposed for now.
MutableCollection<V> by calling RealmDictionary.values. The value collection is a live collection connected to its underlying dictionary. Deletions are allowed though insertions aren't - it isn't possible to insert a value without a key. Core delivers the values as realm_results_t so queries on dictionary objects are funnelled through these.

`RealmDictionary` and `RealmMap` abstractions

Thanks to how the compiler plugin extracts information from the type system it is (almost) possible to work at a RealmMap level, though we aren't exposing a public implementation of it and RealmMap fields aren't allowed either.

To make the implementation more readable and less painful, a number of type aliases have been added:

internal typealias RealmMapEntrySet<K, V> = MutableSet<MutableMap.MutableEntry<K, V>>
internal typealias RealmMapMutableEntry<K, V> = MutableMap.MutableEntry<K, V>
public typealias RealmDictionaryEntrySet<V> = RealmMapEntrySet<String, V>
public typealias RealmDictionaryMutableEntry<V> = RealmMapMutableEntry<String, V>

Object dictionaries

Object dictionaries may contain either regular or embedded objects and null values are allowed. RealmDictionary of objects must be nullable - not the field itself, which is not allowed for any type of Realm collection, but the collection type instead.

Factories

Unmanaged dictionaries can be instantiated by calling the realmDictionaryOf functions that allow the following input values:

realmDictionaryOf(vararg elements: Pair<String, T>)
realmDictionaryOf(elements: Collection<Pair<String, T>>)

Unmanaged RealmDictionaryMutableEntry instances can be used to add key-value pairs to the dictionary through the dictionary's entry set and can be created by calling the realmDictionaryEntryOf functions which accept the following input values:

realmDictionaryEntryOf(pair: Pair<String, V>)
realmDictionaryEntryOf(key: String, value: V)
realmDictionaryEntryOf(entry: Map.Entry<String, V>)

Queries on dictionaries

There is no direct way to parse a query on a dictionary object through the C-API. However, we can use the realm_results_t object yielded by the C-API when calling RealmDictionary.values to parse a query on the results.

Notifications and change sets

A dictionary change set contains:

the deleted keys
the inserted keys
the changed keys

Pull request plan:

# Conflicts: # .github/workflows/issue-needs-attention.yml

# Conflicts: # packages/test-base/src/commonMain/kotlin/io/realm/kotlin/test/util/TypeDescriptor.kt

…`, `put`, `putAll`, `remove` and `clear` (#1219)

# Conflicts: # packages/jni-swig-stub/realm.i

…aries (#1244)

# Conflicts: # packages/library-base/src/commonMain/kotlin/io/realm/kotlin/internal/RealmObjectHelper.kt # packages/library-base/src/commonMain/kotlin/io/realm/kotlin/internal/RealmSetInternal.kt # packages/test-base/src/androidAndroidTest/kotlin/io/realm/kotlin/test/shared/RealmSetTests.kt

…tent (#1254)

… support for Decimal128 in `copyFromRealm` (#1255)

…1263)

# Conflicts: # packages/external/core # packages/jni-swig-stub/realm.i

clementetb · 2023-02-15T11:49:51Z

packages/test-base/src/commonMain/kotlin/io/realm/kotlin/test/util/TypeDescriptor.kt

@@ -335,7 +345,8 @@ object TypeDescriptor {
        .map { RealmFieldType(CollectionType.RLM_COLLECTION_TYPE_LIST, it) }
    val allSetFieldTypes = elementTypesForSet.filter { it.realmFieldType.setSupport }
        .map { RealmFieldType(CollectionType.RLM_COLLECTION_TYPE_SET, it) }
-    // TODO Dict
+    val allDictionaryFieldTypes = elementTypesForDictionary.filter { it.realmFieldType.dictionarySupport }
+        .map { RealmFieldType(CollectionType.RLM_COLLECTION_TYPE_DICTIONARY, it) }
    val allFieldTypes: List<RealmFieldType> = allSingularFieldTypes + allListFieldTypes


allFieldTypes is missing allSetFieldTypes and allDictionaryFieldTypes

cmelchior

Only missing 3000 lines of tests now. Looking good so far 😄

cmelchior · 2023-02-24T12:03:02Z

packages/test-base/src/androidAndroidTest/kotlin/io/realm/kotlin/test/shared/BacklinksTests.kt

    }

    @Test
    fun deleteSourceObject() {
        val child = realm.writeBlocking {
            val child = this.copyToRealm(Child())

-            val parents = Array(5) {
+            val parents = (1..5).map {


Nitpick... but I find repeat(5) { } easier to read

The problem with repeat is that it doesn't do any mapping and we would have to add the output manually for each iteration. Otherwise I agree, it would look better.

cmelchior · 2023-02-24T12:21:52Z

packages/test-base/src/androidAndroidTest/kotlin/io/realm/kotlin/test/shared/QueryTests.kt

+        listOf("@sum", "@min", "@max", "@avg")
+            .forEach { aggregator ->
+                listOf(
+                    QuerySample::intListField.name, // Just test one Long value


I like these tests, but it seems like it would be easy to forget to update these if we add support for new types. I'm not sure it is worth adding now, but I would create an issue for tracking it. Same for the rest of these tests

I have created #1295

cmelchior · 2023-02-24T12:29:06Z

packages/test-base/src/jvmTest/kotlin/io/realm/kotlin/test/compiler/Utils.kt

+ * built by the compiler. Use it to generate different types of scenarios for nullability of
+ * the element type and the collection field itself.
+ */
+fun getCode(


It would be nice with a slightly more specific function name here, maybe getCodeForCollection or something like that.

packages/test-base/src/jvmTest/kotlin/io/realm/kotlin/test/compiler/CollectionTests.kt

packages/test-base/src/commonTest/kotlin/io/realm/kotlin/test/ExhaustiveCollectionTesting.kt

cmelchior

Done...I think we are missing some corner cases around equality testing for Dictionary but otherwise it looks good 🚀

cmelchior · 2023-02-24T13:35:09Z