NSManagedObject ausserhalb von CoreData verwendbar?

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

  • NSManagedObject ausserhalb von CoreData verwendbar?

    Hallo Leute!

    So, die faulen Tage sind vorbei und ich muss Euch einmal wieder mit einer meiner gefürchteten Grundsatzfragen quälen ... Ihr habt sie schon vermisst, gebt's zu :D

    "Darf man NSManagedObjects auch verwenden, ohne dass diese in einem ManagedObjectContext bestehen bzw. in einem Store gespeichert werden?"

    Zum Hintergrund:

    In meiner App muss ich Dokumenten-Informationen cachen. Diese werden aus den Dateien extrahiert, was aber recht aufwändig ist und daher nicht immer bei Bedarf erfolgen kann (z. B. Previews). Dafür gibt es eine extra Klasse "A", mit entsprechenden Properties und Methoden für den Vergleich / die Sortierung. Ausserdem unterstützt diese Klasse das <NSCoding>-Protokoll und der Cache wurde bisher als Array in einer Plist gespeichert. Aufgrund der potentiell großen Anzahl von Objekten möchte ich nun auf CoreData umstellen ... und es ist für mich der Einstieg in dieses Thema.

    Das Problem:

    Die Meta-Daten liegen nach Abfrage aus dem persistenten Cache in NSManagedObjects vor. Für den Abgleich mit dem lokalen Filesystem benötige ich sie aber etwas "angereichert" mit den o. g. Methoden der Klasse "A". Nun gibt es m. E. drei Alternativen und ich weiss nicht, welche die beste ist:
    1. Nach jedem Fetch übertrage ich in einer Schleife alle Objekte des Ergebnis-Arrays in Objekte der Klasse "A" ... erscheint mir unnötig aufwändig, aber dafür vergleiche ich beim Abmischen "Files <-> Cache" nur Objekte der Klasse "A" miteinander.
    2. Ich definierte eine eigene NSManagedObject-Klasse "B", welche die zusätzlichen Methoden zum Sortieren / Vergleichen erhält. Dann vergleiche ich beim Abmischen "Files <-> Cache" immer Instanzen von A (Files) und B (Cache).
    3. Auch die lokalen Dateien werden in NSManagedObjects der Klasse B gespeichert. Ich vergleiche nur Objekte der Klasse B ... aber darf man die Klasse NSManagedObject überhaupt "ausserhalb von CoreData" verwenden?
    Ich hoffe, das Problem wurde deutlich ... wenn nicht, bitte nachfragen, ich brauche hier wirklich Euren Rat!

    Ciao, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Verstehe das Problem, glaube ich, wirklich nicht ganz.

    Du hast NSManagedObjects und verwaltest passend dazu Daten über ein eigenes Caching System? Warum? Kannst Du die Daten nicht mit in die passenden NSManagedObjects packen?

    Wenn Du die Daten z.B. in eigene Entity mit einer 1:1 Beziehung packst, dann sollten diese über das Faulting wunderbar erst dann in den Speicher geladen werden, wenn diese wirklich benötigt werden.
  • Es ist immer schwer, ein Problem zu vermitteln, über dem man selber schon lange grübelt ... Aussenstehende es aber gar nicht kennen: Mein Fehler :)

    Die Daten (= der Cache) sind ja gerade NSManagedObjects. Sieh' es einfach so: Ich habe zwei sortierte Listen zum Abmischen. Die eine Liste ist das Ergebnis eines Fetches aus CoreData, also NSManagedObjects. Die andere Liste ist quasi eine Dateiliste vom NSFileManager. Für das Abmischen beider Listen wäre es einfach, die Einträge der Dateiliste auch in NSManagedObjects abzulegen ... nur temporär für den Vergleich. Aber ich bin mir nicht sicher, ob das erlaubt ist bzw. wie ich die NSManagedObjects ohne Kontext initialisieren würde.

    Momentan bin ich eigentlich eher auf dem Trip, die Dateiliste in NSStrings zu lassen und diese beim Abmischen nur mit einem NSString-Property des Caches zu vergleichen.

    Sorry, wenn ich wirr rede ... Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ah, jetzt verstehe ich das Problem (hoffentlich). ;)

    Die Daten vom NSFileManager liegen doch, zumindest beim Filename, als NSStrings vor welcher für den Vergleich mit dem NSManagedObjects ausreichen sollte. Damit kannst Du dann das passende NSManagedObject zu einem File ermitteln.

    Aus dem NSString (Filename) erst einmal ein NSManagedObject zu machen, um diesen dann z.B. über isEqual: mit einem anderen NSManagedObject vergleichen zu können macht doch wenig Sinn, oder?

    Evtl. könntest Du eine isEqual: Methode schreiben, welche als Argument auch ein NSString Objekt erhalten kann. Ist dies der Fall, dann wird einfach der Filename des NSManagedObject mit dem übergebenem NSString verglichen und das entsprechende Ergebnis zurück geliefert. Alternativ wäre eine Methode isEqualToFilename: beim NSManagedObject auch nicht schlecht.
  • MCDan schrieb:

    Alternativ wäre eine Methode isEqualToFilename: beim NSManagedObject auch nicht schlecht.

    Das gefällt mir! Läuft also auf die Variante "2" hinaus: ein eigenes NSManagedObject mit individueller Methode zum Vergleichen mit einem String ... den ich wiederum ohne "Heckmeck" aus der File-Liste nehmen kann, wodurch die Klasse "A" eigentlich überflüssig wird.

    Danke für den Anstoss, ich werde das direkt mal umsetzen!

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Danke, MCDan!

    Ich hatte echt zu umständlich gedacht (passiert mir leider häufiger): Nun arbeite ich wie oben angedacht mit einem Array aus NSManagedObject (Cache) und einem aus NSStrings (Dateiliste) und alles ist gut...

    Bis zum nächsten Knoten-im-Gehirn, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Danke, Amin, den In-Memory-Store schaue ich mir morgen mal an, zur Zeit läuft es schon mit dem String-Array für Files richtig gut: Dort reichen mir eigentlich die FIle- und Pfad-Namen und bei Bedarf ein MD5-Hash...

    "isEqual:" zu Überschreiben gibt eine Fehlermeldung :D. aber es ging auch ohne.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ah, wird inzwischen angemosert? Sehr gut, clang macht sich.

    Der Vorteil von -isEqual liegt halt darin, dass man dann einfach die Collectionmethoden nutzen kann. Aber da gibt es ja inzwischen ausreichend Alternativen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?