Core Data - Aufteilen in mehrere Xml-Dateien

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

  • Core Data - Aufteilen in mehrere Xml-Dateien

    Hallo,

    Ich habe vor einen Editor für ein iOS-Spiel zu schreiben und evaluiere gerade ob Core Data dafür in Frage kommt.
    Der Editor besteht aus einigen Entities(zB. Modelle, Gegenstände, NPCs, Quests) und Beziehungen zwischen diesen Entities.
    Soweit sieht es sehr gut aus, allerdings werden momentan alle Daten in einer Xml-Datei gespeichert.

    Da mehrere Leute parallel(lokal) an einigen Daten arbeiten sollen ist es sehr unpraktisch dass die Daten alle in der gleichen Datei sind deshalb würde ich sie gerne aufteilen. Als Optionen gibt es soweit ich das gesehen habe entweder:
    a) Verschiedene Stores
    Das hat dann den Nachteil dass ich Beziehungen über Fetched Properties umsetzen muss, könnte ich aber notfalls machen. Ein weiterer Nachteil ist dass ich die Dateien nicht so frei aufteilen kann wie ich es gerne hätte.
    b) Ableiten von NSAtomicStore
    Ich könnte von NSAtomticStore ableiten und müsste das Speichern/Laden selbst umsetzen. Könnte mir hierzu jemand sagen ob ich hierzu Methoden wiederverwenden kann vom Xml-Store ? Ich würde im Endeffekt nur auf erster Ebene unterscheiden wollen welche Entities in welche Datei gespeichert werden, würde aber ungern das Speichern/Laden der NSManagedObjects per Hand machen, ich hätte gerne eine Lösung die Apples Methode benutzt oder alternativ einen Hinweis welche Methode dafür am Sinnvollsten wäre.

    Oder ist mein Ansatz schlecht bzw. hat jemand eine bessere Idee wie ich mein Projekt umsetzen kann ? Ich hatte schon überlegt das ganze doch ohne Core Data zu machen(zB. über NSCoding) aber Core Data gefällt mir sehr gut, vor allem der Undo/Redo-Support und dass man relativ leichte umsteigen kann zwischen den verschiedenen Store-Types(Xml, Sqlite etc.)

    Ich muss dazu sagen ich habe bisher noch kein OSX-Projekt umgesetzt, nur ein (ziemlich aufwendiges) iOS-Spiel und habe daher noch nicht so viel Erfahrung in der Richtung deswegen kann es gut sein dass schon mein Ansatz zu umständlich ist.

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

  • Übrigens ist auch SQLite als relationales Datenbanksystem nicht für den Mehrbenutzerbetrieb gedacht.
    Auf Grund der Dateibasiertheit dieses relationalen Datenbanksystems wird die Datenbank nämlich gesperrt sobald eine Person daran arbeitet – sogar wenn diese nur liest.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Danke für den Hinweis!

    Also der Plan war dass mehrere Leute lokal an ihrem Rechner eine Datei bearbeiten können(bzw. sollen es dann mehrere sein) und diese dann per Versionskontrolle(Git vermutlich) ihre Arbeit den anderen zur Verfügung stellen können.(Erst wenn sie lokal ihre Änderungen getestet haben)
    Konflikte(wenn mehrere Leute am gleichen Bereich in einer Datei gearbeitet haben) können in Xml-Dateien per Hand oder automatisch gelöst werden.

    Könnte man für diesen Workflow den Core Data Xml-Store nehmen oder bekommt man Probleme wenn Leute Entities parallel angelegt haben und die Datei dann zusammenführt ? (Mir ist klar dass es dazu kommen kann wenn man zB. eine Entity löscht die der andere gerade benutzen will aber ich rede primär vom Anlegen und Editieren von Entities da Dinge wie das Löschen von Entities vorher abgesprochen wird oder notfalls in der Xml-Datei korrigiert werden kann)
  • Nightmare_82 schrieb:

    Könnte man für diesen Workflow den Core Data Xml-Store nehmen oder bekommt man Probleme wenn Leute Entities parallel angelegt haben und die Datei dann zusammenführt ?

    Theoretisch könnte das funktionieren. In der Praxis bekommst Du jedoch wahrscheinlich sehr schnell Konflikte und zerschossene Dateien. Core-Data prüft beispielsweise auch immer die Versionsnummern der Dateien. Die Migration solcher Stores macht wahrscheinlich richtig Spaß.

    Wie wäre es mit KeyedArchivern (PList-Format) als Alternative? Ich würde auf jeden Fall ein lesbares Format verwenden.
    „Meine Komplikation hatte eine Komplikation.“
  • Auch wenn ich das vermutlich nicht in mein aktuelles Projekt einbaue : Kann mir noch jemand sagen was der beste Weg wäre einen CoreDataStore so abzuändern dass er die Daten in mehrere Xml-Dateien aufteilt ?

    Die Sache ist ich habe viele Daten mit einigen Beziehungen(beispielsweise NPCs haben Gegenstände). Wenn ich mehrere Stores benutze um die Daten aufzuteilen müsste ich Fetched Properties nutzen was eher unschön ist, es wäre super wenn es einen sauberen Weg gäbe einen Store in mehrere Xml-Dateien aufzuteilen.