Objektgraph mit Im- / Export ... Core Data oder was?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Objektgraph mit Im- / Export ... Core Data oder was?

      Hallo zusammen,

      wie angekündigt beschäftige ich mich gerade mit einer neuen App-Idee und würde gerne Eure Meinung zu einer Grundsatzfrage kennen:

      Die Daten der App werden in einer überschaubaren Anzahl von Objektgraphen vorliegen, nennen wir sie mal A, B, C, ... insgesamt so um die zehn "Haupt-Objekte". Diese beinhalten diverse Attribute und 1-2 Relationen zu anderen "Sub-Objekten". Essentiell sind Import- / Export-Funktionen, die es erlauben, einzelne Haupt-Objekt (inkl. ihrer Abhängigkeiten) aus den Daten zu exportieren, z. B. per Mail zu verschicken oder zum Download anzubieten, und wieder (bei einem anderen Benutzer) zu importieren.

      Ich wollte die Daten mittels Core Data speichern, und bin mir nun unsicher, wieder dieser Import / Export zu realisieren ist. Eigentlich hatte ich erwartet, dass es hierzu relativ einfache Methoden gibt, aber wie es ausschaut, müsste ich ein entsprechend abgefragtes Objekt in ein XML o. ä. überführen bzw. aus einem XML in das Datenmodell einfügen, korrekt?

      Da ich von Natur aus faul bin (und es sich nur um relativ wenige Objekte und Attribute handelt), überlege ich nun, jedes Haupt-Objekt in eine PLIST zu persistieren. Nicht elegant, aber leicht / schnell gelöst und die Import- / Export-Funktion kommt quasi gratis mit dazu: Einfach die neue PLIST in's Document-Directory speichern und fertig (bzw. aus diesem kopieren).

      Was sollte Eurer Ansicht nach gewinnen: Der Anspruch an Perfektion oder die Bequemlichkeit? ?(

      Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

    • ioscampus schrieb:

      Spricht irgendetwas gegen iCloud Documents?
      Ich muss gestehen, mich noch nicht wirklich mit iCloud Documents beschäftigt zu haben. Was spräche denn für deren Verwendung? Ich hätte bei meiner Idee nicht direkt an eine Dokumenten-basierte App gedacht, und iCloud-Funktionalität ist auch nicht im Vordergrund?

      Steh' ich auf'm Schlauch?

      Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

    • macmoonshine schrieb:

      Bei mir enden solche Bequemlichkeitslösungen letztendlich dann doch in der sauberen Umsetzung, weil ich irgendwann festgestelle, dass ich (zu viele) Standardfunktionen nachbaue. Also nimm lieber direkt CoreData.
      Ich hatte befürchtet, dass jemand dies schreibt ;) Meine Erfahrung sagt das gleiche, zumal mich Bastellösungen nach einiger Zeit schon prinzipbedingt ärgern und ich den Ehrgeiz entwickle, sie auszuräumen. Soll doch die App eh zum Vertiefen einiger Themen dienen. Also CoreData.

      Sehe ich es richtig, dass ich zum Export z. B. eine NSDictionary mit einem aus CoreData abgefragtem Objekt erstellen müsste, um diese dann als XML (JSON, PLIST, ...) zu speichern? Für den Import dann umgekehrt: Datei einlesen, in ein NSDictionary umwandeln und ein CoreData Objekt (inkl. Relationen) einfügen. Gibt es da etwas Elegantes?

      Grüße, Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

    • MyMattes schrieb:

      ioscampus schrieb:

      Spricht irgendetwas gegen iCloud Documents?
      Ich muss gestehen, mich noch nicht wirklich mit iCloud Documents beschäftigt zu haben. Was spräche denn für deren Verwendung? Ich hätte bei meiner Idee nicht direkt an eine Dokumenten-basierte App gedacht, und iCloud-Funktionalität ist auch nicht im Vordergrund?
      Steh' ich auf'm Schlauch?

      Mattes

      Du hast halt geschrieben, dass du Dokumente sauber ex- und importieren möchtest. Da finde ich es nahliegend gleich eine Dokumenten-basierte App zu nehmen. Dann hast du den Import und Export mit minimalen Aufwand. Natürlich kenne ich dein Datenmodel nicht. In Abhängigkeit davon kann es eben auch keinen Sinn machen - wenn zum Beispiel alles mit allem zusammenhängt und es keine abgeschlossenen Einheiten gibt, die man in einem Dokument bündeln kann.

    • Ich reanimiere einmal:

      Es wird nun konkret, die Anwendung ist (auf Basis von Core Data) in der Entwicklung und das Thema Ex- / Import steht an. Ich möchte dies entweder per <NSCoding> oder durch direkte Nutzung eines NSDictionaries realisieren und habe auch ein paar interessante Sachen auf GitHub gefunden. Leider habe ich bzgl. Relationen noch einen Knoten im Gehirn.

      Nehmen wir an, ich habe folgende Relationen der Entitäten A, B, C, D:

      A <->> B
      A <->> C
      A <->> D
      D <<-> B
      D <<-> C

      Wenn ich nun diesen Graphen exportiere und wieder importiere, erwarte ich, dass Dubletten der Entitäten B und C erzeugt werden ... zugegebenermaßen erstmal nur eine Vermutung, da ich es noch nicht programmiert habe.

      Wie schaffe ich, dass beim Erzeugen der Core Data Objekte die Relationen so restauriert werden, dass mehrere ursprüngliche Relationen zu einem Objekt nicht Kopien erzeugen. Oder denke ich viel zu kompliziert?

      Gruß, Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes () aus folgendem Grund: Relationen im Beispiel korrigiert

    • MyMattes schrieb:

      Wenn ich nun diesen Graphen exportiere und wieder importiere, erwarte ich, dass Dubletten der Entitäten B und C erzeugt werden ... zugegebenermaßen erstmal nur eine Vermutung, da ich es noch nicht programmiert habe.
      Also wenn Du das selber mittels eines Dictionaries frickelst, musst Du Dich um Dubletten selber kümmern. Logisch. Verwendest Du NSCoding, dann geht das automatisch, d.h. jedes Objekt hat eine eindeutige Identität in so einem Archiv und wird auch nur einmal gespeichert und der Objektgraph dann auch passend wiederhergestellt.

    • So, das Thema ist nun durch:

      Ich habe jeder NSManagedObject-Subclass eine eigene Methode zum Exportieren in bzw. Importieren aus einem Dictionary spendiert. Beim Importieren wird geprüft, ob eine entsprechende Entität schon existiert. Hierzu verwende ich das Subset an Attributen, das einen eindeutigen Schlüssel bildet. Gibt es ein entsprechendes Objekt schon, benutze ich dieses, ansonsten lege ich ein neues an und fülle dessen Attribute. Nun stelle ich die Relationen zu den übergeordneten Objekten her.

      Fluppt sehr gut.

      Interessieren würde mich aber schon noch die Auflösung zu @gandhis Bemerkung: Inwiefern werden die Dubletten bei Verwendung von <NSCoding> "automatisch" vermieden? Da NSManagedObject dieses Protokoll nicht implementiert, müsste ich dies ja selber machen ... und würde genau den oben beschrieben Weg gehen. Automatisch ist doch anders.

      Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()

    • Um NSCoder zu verwenden, musst Du ja nur "initWithCoder" und "encodeWithCoder" implementieren. Das war's. Um alles andere kümmert sich der NSKeyedArchiver: Herstellen des Objektgraphen, vermeiden von Dubletten im Archiv (da werden halt eindeutige Objekt-IDs vergeben und wenn der Archiver merkt, dass er das Objekt mit dieser ID schonmal gespeichert hat, wird nur eine Referenz erzeugt, nicht aber das Objekt erneut ins Archiv gepackt).

      Also alles das, was Du jetzt von Hand implementiert hast, hättest Du von NSCoding geschenkt bekommen.

    • gandhi schrieb:

      Herstellen des Objektgraphen, vermeiden von Dubletten im Archiv (da werden halt eindeutige Objekt-IDs vergeben und wenn der Archiver merkt, dass er das Objekt mit dieser ID schonmal gespeichert hat, wird nur eine Referenz erzeugt, nicht aber das Objekt erneut ins Archiv gepackt).
      Danke für Deine Rückmeldung.

      Soweit alles klar, aber die Dubletten, die ich meinte, entstünden nicht beim Speichern im Archiv, sondern beim Wiederherstellen in Core Data: Um bei meinem Beispiel oben zu bleiben, wird das Element B zweimal beim referenziert, einmal als Sub-Entity von A und einmal von D. Wenn ich bei der Wiederherstellung im zweiten Fall nicht anhand eines unique keys erkennen kann, dass es sich um das gleiche Objekt handeln soll, würde ein neues Element B' erzeugt und der neue Graph sähe wie folgt aus:

      Ursprünglicher Graph:

      A <->> B
      A <->> C
      A <->> D
      D <<-> B
      D <<-> C

      Neuer Graph:

      A <->> B
      A <->> C
      A <->> D
      D <<-> B'
      D <<-> C'

      Ich hätte für B und C also Dubletten. Dies kann ich verhindern, indem ich vor'm Anlegen eines neuen Core Data Objektes prüfe, ob eines mit identischem Key bereits existiert, und dann dieses referenziere. Dieser Schritt ist aber unabhängig davon, ob die Daten in einem NSKeyedArchive oder NSDictionary lagen, er ist beim Restaurieren der Core Data Entitäten notwendig ... und muss meines Wissen eben programmiert werden. Ich lasse mich aber gerne eines Besseren belehren :)

      Mattes
      Diese Seite bleibt aus technischen Gründen unbedruckt.

    • Also ich würde das nicht in die MO-Subklassen packen, denn da gehört es nicht hin. Ein dictionary kriegst Du ja über dictionaryForKeys oder so ähnlich, bin gerade unterwegs.

      Schreibe Dir einen eigene Exporter, der sich dann um alle constraints (dubletten, Umwandlung von Werten) etc kümmert. So hast Du klare Zuständigkeiten und kleisterst Dir Deine MOs nicht zu.