NSFetchedResultsController komplexe Abrufanforderung und Modell
Ich versuche, mein CoreData-Modell für diese Situation zu entwerfen:
Wir haben Song object, die eine to-many Beziehung mit einigen List haben.
Jedes List hat name -Eigenschaft und auch eine to-many-Beziehung mit Song
Diese Viele-zu-Viele-Beziehung wird benötigt, weil ein Song in jedem List gleichzeitig dargestellt werden kann.
Ich muss irgendwie eine Liste von Song s erhalten, die nach diesen Headern gruppiert ist (Name von List ) mit NSFetchedResultsController (da der Benutzer vielleicht 10.000 Songs hat und ich möchte es nicht irgendwo in NSArray speichern ).
Wenn ich versuche sectionNameKeyPath: mit einem bestimmten Wert zu setzen, z. @"List.name" Ich habe einen Fehler "to-many Beziehung ist nicht erlaubt" und das macht natürlich Sinn.
Ich brauche also Hilfe, wie ich mein Modell so gestalten kann, dass Song s und einige List s wie "History" / "Next Playing" usw. vorliegen und alle Daten mit% co_de abgerufen werden können %.
Jede Hilfe wird geschätzt. Wenn meine Erklärung nicht klar war, bitte fragen Sie nach weiteren Informationen.
Teil meines Codes:
%Vor%2 Antworten
Die Verwendung von FRC kann hervorragend für die Anzeige von Daten für Ihren Benutzer sein, aber bei der Verwendung kann es diktieren, wie Ihr Modell strukturiert sein muss und nicht, wie Sie sonst glauben, dass Ihre Modell-Entitäten und Beziehungen strukturiert sein sollten. In Ihrem Fall sieht es so aus, als wollten Sie eine Liste von tatsächlichen States für Songs in Ihrer Datenbank sehen, anstatt eine Liste a von Songs. Jede Zustandsinstanz würde eine Eins-zu-Eins-Beziehung zu einem Lied haben, und der Zustand könnte eine Eins-zu-Viele-Beziehung in Ihren Listen haben, z. mit einer History-Liste verbunden sein, playNext list, zZ spielen "list" (mit nur einer Instanz im letzten Fall). Wenn Sie Ihre FRC-Entität auf diesen State -Entity und den mit der Liste verknüpften Schlüsselpfad des Abschnitts, in dem sich der Status befindet, festlegen, können Sie die obige Anforderung erfüllen, ohne indexPaths bearbeiten oder mit mehreren FRCs arbeiten zu müssen. Wenn Sie diese separate Entität verwenden, können Sie später weitere Attribute hinzufügen, z. B. das Datum der letzten Wiedergabe oder ein Aggregat für die Wiedergabezeiten. All dies könnte auf der State-Entity statt auf der Song-Entity selbst erfolgen.
Sie müssen keinen FRC verwenden, um ein übermäßiges Laden von Daten zu verhindern, es ist nicht das, was das tut. Die Stärke des FRC liegt in der Beobachtung des Kontextes, um Veränderungen zu erkennen. Diese Leistung funktioniert auch nicht gut, wenn Sie versuchen, in Beziehungen zu navigieren, so dass Sie in diesem Fall wahrscheinlich auch keinen FRC nutzen.
Was Ihre Datennutzung einschränkt, sind verwaltete Objekte, wenn sie nicht mehr benötigt werden (in manchen Fällen manuell, aber das System wird dies bei Bedarf selbst tun) und die Abrufanforderung stapelweise. Wenn Sie eine Batch-Größe für die Abrufanforderung festlegen, wird das zurückgegebene NSArray nur Daten in den Speicher laden. Der FRC profitiert davon, kontrolliert ihn aber nicht - und wenn Sie vergessen, die Charge hinzuzufügen, wird der FRC das nicht für Sie tun!
Sie können also entweder ein System einrichten, in dem Sie mehrere Arrays haben, 1 pro Abschnitt, und alles selbst verwalten. Oder Sie könnten mehrere FRCs 1 für jeden Abschnitt verwenden und die Indexpfade so manipulieren, dass alles zusammen hängt.
Oder Sie können Ihr Datenmodell ändern, indem Sie Zwischenobjekte hinzufügen, die die Mitgliedschaft eines Song in einem List darstellen, da dadurch die Viele-zu-Viele-Beziehungen unterbrochen werden und Sie eine bearbeitbare Beziehung in den Vordaten erhalten und Sortierdeskriptoren. In diesem Fall wäre die neue Entität diejenige, die Sie für die FRC abgerufen haben. Beachten Sie das oben erwähnte Problem über Änderungsverfolgung in Beziehungen, achten Sie jedoch darauf, was Sie ändern und wie ...
Tags und Links objective-c ios core-data nsfetchedresultscontroller