Modélisation de sous-collections dans MongoDB Realm Sync

Votre code a fière allure et vous vous dirigez dans la bonne direction, donc cette réponse est plus d'explications et de suggestions sur la modélisation que le code dur.

Tout d'abord, les objets Realm sont paresseusement chargé ce qui signifie qu'ils ne sont chargés que lorsqu'ils sont utilisés. Des dizaines de milliers d'objets auront très peu d'impact sur la mémoire d'un appareil. Supposons donc que vous ayez 10 000 utilisateurs et que vous les "chargez tous"

let myTenThousandUsers = realm.objects(UserClass.self)

euh, pas grave. Cependant, en faisant cela

let someFilteredUsers = myTenThousandUsers.filter { $0.blah == "blah" }

va (pourrait) créer un problème - si cela renvoie 10 000 utilisateurs ils sont tous chargés en mémoire peut-être submerger l'appareil. Il s'agit d'une fonction Swift et la "conversion" des données paresseuses de Realms à l'aide de Swift doit généralement être évitée (selon le cas d'utilisation)

L'observation de ce code à l'aide de Swift .forEach

realm.objects(Project.self).forEach { (project) in
   // Access fields     
}

peut causer des problèmes en fonction de ce qui est fait avec ces objets de projet - les utiliser comme source de données tableView peut poser problème s'il y en a beaucoup.

La deuxième chose est la question sur la limite de 16 Mo par document. Pour plus de clarté, un document Atlas est ceci

{
   field1: value1,
   field2: value2,
   field3: value3,
   ...
   fieldN: valueN
}

où valeur peut être n'importe lequel des types de données BSON tels que d'autres documents, des tableaux et des tableaux de documents.

Dans votre structure, le var tasks = RealmSwift.List<Task>() où Task est un objet intégré . Bien que les objets conceptuellement intégrés soient des objets, je pense qu'ils comptent pour une seule limite de document car ils sont intégrés (corrigez-moi si je me trompe); à mesure que leur nombre augmente, la taille du document joint augmente - en gardant à l'esprit que 16 Mo de texte représentent une ÉNORME quantité de texte, ce qui équivaudrait/pourrait équivaloir à des millions de tâches par projet.

La solution simple est de ne pas les intégrer et de les laisser se tenir debout.

class Task: Object {
    @objc dynamic var _id: String = ObjectId.generate().stringValue
    @objc dynamic var _partition: String = "" 
    @objc dynamic var name: String = ""
    @objc dynamic var status: String = "Pending"
    override static func primaryKey() -> String? {
        return "_id"
    }
}

Ensuite, chacun peut être de 16 Mo, et un "nombre illimité" peut être associé à un seul projet. L'un des avantages des objets incorporés est un type de suppression en cascade où, lorsque l'objet parent est supprimé, les objets enfants le sont également, mais avec une relation 1-plusieurs du projet aux tâches - la suppression d'un groupe de tâches appartenant à un parent est facile.

Oh - un autre cas pour ne pas utiliser d'objets intégrés - en particulier pour ce cas d'utilisation - est qu'ils ne peuvent pas avoir de propriétés indexées. Indexation peut considérablement accélérer certaines requêtes.