Core Data- og Swift: Migrations
14
Del
to
Del

Dette Cyber ​​mandag Envato Tuts + Kursene vil bli redusert til bare $ 3. Ikke gå glipp av
Dette innlegget er en del av en serie kalt kjernedata og Swift.Core Data- og Swift. Mer NSFetchedResultsControllerCore Data- og Swift: subclassing NSManagedObject

I tidligere artikler i denne serien, vi har støtt en irriterende problem som vi må løse. Når vi endrer datamodell av en Core data program, blir vedvarende butikken uforenlig med datamodellen. Resultatet er en krasj på lanseringen, gjengi programmet ubrukelig, et alvorlig problem hvis dette skjer med en applikasjon i App Store.

Vårt program krasjer fordi vi påkalle avbryte hvis du legger den vedvarende butikken til vedvarende butikken koordinator er mislykket. For å være klar, avbrytelsesfunksjonen fører til at programmet avsluttes umiddelbart
gjøre {//Legg Vedvarende Store til Vedvarende Butikk koordinator prøve persistentStoreCoordinator.addPersistentStoreWithType (NSSQLiteStoreType, konfigurasjon: null, URL: URLPersistentStore, alternativer: nil)}. Fangsten { //Befolke Feil Var Userinfo = [String: AnyObject] () Userinfo [NSLocalizedDescriptionKey] = ". Det var en feil å opprette eller laste lagrede data programmets" Userinfo [NSLocalizedFailureReasonErrorKey] = "Det oppstod en feil å opprette eller laste lagrede data programmets." Userinfo [NSUnderlyingErrorKey] = feil som NSError la wrappedError = NSError (domene: "com.tutsplus.Done", kode: 1001, Userinfo: Userinfo) NSLog ("Uløste error \\ (wrappedError), \\ (wrappedError.userInfo)") abort ()}

Det er imidlertid ikke nødvendig å avslutte vår søknad, enn si krasjer den. Hvis kjernedata forteller datamodellen og vedvarende butikken er inkompatible, så er det opp til oss å løse det.

I denne artikkelen vil vi diskutere to alternativer for å gjenopprette fra en slik situasjon, migrerer den vedvarende butikken og skape en ny vedvarende butikk som er kompatibel med den modifiserte datamodell.

1. Problemet

La meg først avklare problemet at vi prøver å løse. Last ned prøveprosjektet vi skapte i forrige artikkel, og kjøre det i simulatoren. Søknaden bør kjøre og fungere helt fint.

Åpne Done.xcdatamodeld Hotell og legge et attributt updatedAt av type Dato
til Element enhet. Kjøre programmet en gang til, og legg merke til hvordan programmet krasjer så snart den er lansert. Heldigvis gir kjernedata oss en anelse om hva som gikk galt. Ta en titt på resultatet i Xcode konsoll
Ferdig. [897: 14527] CoreData: error: -addPersistentStoreWithType: SQLite konfigurasjon: (null) URL:file:///Users/Bart/Library/Developer/CoreSimulator/Devices/A263775B-4D73-48C8-BD79-825E0BED5128/data/Containers/Data/Application/E46663CA-79AF-4645-AF78-0A17236943E1/Documents/Done.sqlite alternativer: (null) ... returnert feil Feil Domain = NSCocoaErrorDomain Code = 134100 "(null)" Userinfo = {metadata = {NSPersistenceFrameworkVersion = 640; NSStoreModelVersionHashes = {Element = < 4c880226 3219fc66 283b28c5 54f026dc 7f95af5f c19fb76e 255a26a7 2a2a79f5 >; }; NSStoreModelVersionHashesVersion = 3; NSStoreModelVersionIdentifiers = (""); NSStoreType = SQLite; NSStoreUUID = "F0F98261-4F60-451A-9606-91E1F60425B9"; "_NSAutoVacuumLevel" = 2;}, fornuft = Modellen brukes til å åpne butikken er uforenlig med den som ble brukt for å lage den butikken} med userinfo ordboken {metadata = {NSPersistenceFrameworkVersion = 640; NSStoreModelVersionHashes = {Element = < 4c880226 3219fc66 283b28c5 54f026dc 7f95af5f c19fb76e 255a26a7 2a2a79f5 >; }; NSStoreModelVersionHashesVersion = 3; NSStoreModelVersionIdentifiers = (""); NSStoreType = SQLite; NSStoreUUID = "F0F98261-4F60-451A-9606-91E1F60425B9"; "_NSAutoVacuumLevel" = 2; }; Grunnen = "Modellen brukes til å åpne butikken er uforenlig med den som ble brukt for å lage den store";}

Nær slutten, forteller grunndata oss at datamodellen som ble brukt til å åpne den vedvarende butikken er uforenlig med datamodell som ble brukt til å lage den vedvarende butikken. Vente. Hva?

Når vi lanserte programmet for første gang, skapte kjernedata en SQLite database basert på datamodellen. Men fordi vi endret datamodell ved å legge til et attributt til Element enhet, updatedAt, Core data ikke lenger forstår hvordan det bør lagre Element poster i SQLite database. Med andre ord, ikke lenger er kompatibel med vedvarende lagre den modifiserte datamodellen, den SQLite database, skapte det tidligere.

2. Løsningen

Heldigvis for oss, har noen smarte ingeniørene hos Apple laget en løsning for å trygt endre en datamodell uten å kjøre inn kompatibilitetsproblemer. For å løse problemet vi står overfor, må vi finne en måte å fortelle kjernedata hvordan én versjon av datamodellen er knyttet til en annen versjon. Det er riktig, versjonsdatamodellen er en del av løsningen.

Med denne informasjonen, Core Data kan forstå hvordan den vedvarende butikken må oppdateres for å være kompatibel med den modifiserte datamodell, det vil si den nye versjonen av datamodellen. Med andre ord, må vi levere grunndata nødvendig informasjon for å migrere vedvarende butikken fra én versjon av datamodell til en annen.

3. Migrations

Det finnes to typer av vandringer, lette og tunge vandringer. Ordene lette Hotell og tung
er ganske beskrivende, men det er viktig at du forstår hvordan kjernedata håndterer hver type migrasjon.

Lette Migrations

Lette vandringer krever svært lite arbeid fra din side, utvikleren. Jeg anbefaler sterkt at du velger en lett migrasjon over en tung migrasjon når du kan. Kostnaden for en lett migrasjon er vesentlig lavere enn for en tung migrasjon.

Selvfølgelig, er baksiden av lette vandringer at de er mindre kraftig enn tunge vandringer. De endringer du kan gjøre til en datamodell med lette vandringer er begrenset. For eksempel kan en lett migrasjon du legge til eller endre navn på attributter og enheter, men du kan ikke endre type for attributtet eller relasjonen mellom eksisterende enheter.

Lette migreringer er ideelle for å utvide datamodellen, legger attributter og enheter. Hvis du har tenkt å modifisere relasjoner eller endre attributt typer, så du er i for en vill tur med tunge vandringer.

Store Migreringer

Store overføringer er litt vanskeligere. La meg omformulere spørsmålet. Tunge vandringer er en smerte i nakken, og du bør prøve å unngå dem hvis mulig. Tunge migreringer er kraftige, men at makten kommer til en kostnad. Tungvandringene krever mye arbeid og testing for å sikre at overgangen blir fullført og, enda viktigere, uten tap av data.

Vi går inn i en verden av tunge vandringer hvis vi gjør endringer som kjernedata ikke automatisk kan antyde for oss ved å sammenligne versjoner av datamodellen. Kjerne Data vil da trenge en kartleggingsmodell for å forstå hvordan versjonene av datamodellen forholder seg til hverandre. Fordi tunge vandringer er et komplekst tema, vil vi ikke dekke det i denne serien.

4. Versjons

Hvis du har jobbet med Ruby on Rails eller andre rammeverk som støtter vandringer, da kjernedata migreringer vil gjøre mye fornuftig for deg. Ideen er enkel, men kraftig. Kjernen data gjør oss til versjon datamodellen, og dette gjør at vi kan trygt endre datamodellen. Kjernen data inspiserer versjondatamodell for å forstå hvordan den vedvarende butikken er relatert til datamodellen. Ved å se på versjondatamodellen, vet det også hvis den vedvarende butikken må overføres før den kan brukes sammen med den gjeldende versjonen av datamodellen.

Versjons og vandringer går hånd i hånd. Hvis du ønsker å forstå hvordan vandringer fungere, må du først forstå hvordan versjon Core data datamodell. La oss se på to-do program vi opprettet i forrige artikkel. Som vi så tidligere, og legger til et attributt, updatedAt, til elementet foretakets resultater i den vedvarende butikken å være uforenlig med den modifiserte datamodell. Vi nå forstår årsaken til dette.

La oss starte med blanke ark ved å åpne Done.xcdatamodeld Hotell og fjerne updatedAt attributtet fra Element enhet. Det er på tide å lage en ny versjon av datamodellen.

Med datamodellen valgt, velger du Legg Model versjon ...
fra Editor
menyen. Xcode vil be deg om å gi navn til den nye datamodellen versjon og, enda viktigere, på hvilken versjon den nye versjonen skal være basert. For å sikre kjernedata kan migrere den vedvarende butikken for oss, er det viktig at du velger den forrige versjonen av datamodellen. I dette eksempelet har vi bare ett valg.

Resultatet av denne handlingen er at vi nå kan se tre data modellfiler i Prosjekt Navigator
. Det er ett toppnivå datamodell med en .xcdatamodeld
forlengelse og to barn med en .xcdatamodel
forlengelse.

Du kan se .xcdatamodeld
fil som en pakke for versjonene av datamodellen, med hver versjon representert med en .xcdatamodel
fil. Du kan kontrollere dette ved å Vis i Finder
høyreklikke på .xcdatamodeld
fil og velge. Dette vil ta deg til datamodellen i Xcode prosjekt. Du skal se de to versjonene av datamodellen, Done.xcdatamodel Hotell og Ferdig 2
.xcdatamodel
.

Har du lagt merke til i < b> Prosjekt Navigator
at en av versjonene har en grønn hake? Denne merkingen indikerer hva dagens modell versjonen er, Done.xcdatamodel
i dette eksemplet. Med andre ord, selv om vi har laget en ny versjon av datamodellen, det er ikke tatt i bruk av vår søknad ennå. Før vi endrer dette, skjønt, må vi fortelle kjernedata hva den skal gjøre med versjondatamodell.

Vi må fortelle kjernedata hvordan du overfører den vedvarende butikken for datamodellen. Vi gjør dette når vi legger den vedvarende butikken til den vedvarende butikken koordinator i AppDelegate.swift
. I gjennomføringen av persistentStoreCoordinator eiendom, skaper vi den vedvarende butikken koordinator og legge til et vedvarende butikken til det ved å påberope addPersistentStoreWithType (_: konfigurasjon: URL: alternativer :). Dette skulle være kjent nå.

Den fjerde parameter med denne metoden er en ordbok av alternativer, som for tiden er null. Denne ordlisten alternativer inneholder instruksjoner for kjernedata. Det gir oss muligheten til å fortelle den vedvarende butikken koordinator hvordan det skal migrere vedvarende butikk som vi ønsker å legge til det.

Ta en titt på følgende kodebiten som passerer vi en ordliste over alternativer med to- nøkkelverdipar
//erklære Optionslet alternativer = [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]. //Legg Vedvarende Store til Vedvarende Butikk Coordinatortry persistentStoreCoordinator.addPersistentStoreWithType (NSSQLiteStoreType, konfigurasjon: null, URL: URLPersistentStore, alternativer: opsjoner)

Den første nøkkelen, NSMigratePersistentStoresAutomaticallyOption, forteller kjernedata som vi vil at det skal forsøke å migrere vedvarende butikken for oss. Den andre nøkkelen, NSInferMappingModelAutomaticallyOption, instruerer kjernedata for å antyde kartlegging modell for migrasjon. Dette er akkurat det vi ønsker. Det skal fungere uten problemer så lenge vi har å gjøre med lette vandringer.

Med denne endringen, er vi klare til å overføre datamodellen til den nye versjonen har vi laget en liten stund siden. Start med å velge den nye versjonen, Ferdig 2.xcdatamodel
, og legge til en ny attributt updatedAt av type Dato
til Element enhet.

Vi trenger også å markere ny datamodell versjon som versjonen til bruk av grunndata. Velg
Done.xcdatamodeld
i Prosjekt Navigator Hotell og åpne File Inspektør
til høyre. I avsnittet Model versjon
, sette Gjeldende
til Ferdig 2
.

Prosjekt Navigator
, Ferdig 2.xcdatamodel
skal nå ha en grønn hake i stedet for Done.xcdatamodel
.

Med denne endringen, kan du trygt bygge og kjøre programmet. Hvis du har fulgt fremgangsmåten ovenfor, bør kjernedata automatisk migrere vedvarende butikken for deg ved å dedusere kartlegging modell basert på versjondatamodell.

Legg merke til at det er noen begrensninger du bør være klar over. Hvis du kjører inn i en krasj, så du har gjort noe galt. For eksempel, hvis du har satt den datamodell versjonen til Ferdig 2.xcdatamodel
, kjøre programmet, og deretter gjøre endringer i Ferdig 2.xcdatamodel
, så du vil mest sannsynlig kjøre inn i en krasj på grunn av den vedvarende butikken å være uforenlig med datamodellen. Lette migreringer er relativt kraftig og de er enkle å implementere, men det betyr ikke at du kan endre datamodellen til enhver tid.

Data laget av en programvare-prosjekt krever omsorg, oppmerksomhet og forberedelse. Migrations er stor, men de bør brukes med måte. Krasjer er ikke noe problem under utvikling, men de er katastrofale i produksjon. I neste avsnitt tar vi en nærmere titt på hva dette betyr, og hvordan du kan forhindre krasj på grunn av en problematisk migrasjon.

5. Unngå krasjer

Jeg har aldri kommet i en situasjon som ikke er garantert å kalle abort i produksjon, og det smerter meg når jeg besøker et prosjekt der Apples standard implementering for å sette opp grunndata stabelen brukes, hvor abort er kalt når du legger til et vedvarende butikken er mislykket.

Unngå abort er ikke så vanskelig, men det krever noen få linjer med kode og informere brukeren om hva som gikk galt i tilfelle noe går galt. Utviklere er bare mennesker og vi alle gjør feil, men det betyr ikke at du bør kaste inn håndkleet og ringe avbryte

Trinn 1:. Bli kvitt abort

Start med å åpne AppDelegate.swift Hotell og fjerne linjen som vi kaller abort. Det er det første skrittet til en lykkelig bruker
gjøre {//Erklærer Valg la alternativer = [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]. //Legg Vedvarende Store til Vedvarende Butikk koordinator prøve persistentStoreCoordinator.addPersistentStoreWithType (NSSQLiteStoreType, konfigurasjon: null, URL: URLPersistentStore, alternativer: opsjoner)} fangst {//Befolke Error Var Userinfo = [String: AnyObject] () Userinfo [NSLocalizedDescriptionKey] = ". Det var en feil å opprette eller laste lagrede data programmets" Userinfo [NSLocalizedFailureReasonErrorKey] = "Det oppstod en feil å opprette eller laste lagrede data programmets." Userinfo [NSUnderlyingErrorKey] = feil som NSError la wrappedError = NSError (domene: "com.tutsplus.Done", kode: 1001, Userinfo: Userinfo) NSLog ("Uløste error \\ (wrappedError), \\ (wrappedError.userInfo)")}
Trinn 2: Flytte Inkompatibel butikken

Hvis grunndata oppdager at den vedvarende butikken er uforenlig med datamodellen, må vi først flytte uforenlig butikken til et trygt sted. Vi gjør dette for å sikre at brukerens data er ikke tapt. Selv om datamodellen er uforenlig med den vedvarende butikken, kan du være i stand til å gjenopprette data danne det. Ta en titt på den oppdaterte gjennomføringen av persistentStoreCoordinator eiendom i AppDelegate.swift
lat Var persistentStoreCoordinator. NSPersistentStoreCoordinator = {//Initial Vedvarende Butikk koordinator la persistentStoreCoordinator = NSPersistentStoreCoordinator (managedObjectModel: self.managedObjectModel) //URL Vedvarende Butikk la URLPersistentStore = self.applicationStoresDirectory () URLByAppendingPathComponent ("Done.sqlite") gjør {//Erklærer Valg la alternativer = [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]. //Legg Vedvarende Store til Vedvarende Butikk koordinator prøve persistentStoreCoordinator .addPersistentStoreWithType (NSSQLiteStoreType, konfigurasjon: null, URL: URLPersistentStore, alternativer: opsjoner)} catch {la fm = NSFileManager.defaultManager () hvis fm.fileExistsAtPath (URLPersistentStore.path!) {la nameIncompatibleStore = self.nameForIncompatibleStore () la URLCorruptPersistentStore = . self.applicationIncompatibleStoresDirectory () URLByAppendingPathComponent (nameIncompatibleStore) trenger {//Flytt Uforenlig Butikk prøve fm.moveItemAtURL (URLPersistentStore, toURL: URLCorruptPersistentStore)} catch {la moveError = feil som NSError print ("\\ (moveError), \\ (moveError.userInfo ) ")}}} returnere persistentStoreCoordinator} ()

Merk at jeg har endret verdien av URLPersistentStore, plasseringen av den vedvarende butikken. Den peker til en katalog i Dokumenter katalog i programmets sandkasse. Gjennomføringen av applicationStoresDirectory (), en hjelper metode, er grei som du kan se nedenfor. Det er sikkert mer utførlig enn i Objective-C. Merk også at jeg tvinge pakke resultatet av banen () av ​​URL konstant, fordi vi kan trygt anta at det er et program som støtter katalog i programmets sandkasse, både på iOS og på OS X.
privat func applicationStoresDirectory () - > NSURL {la fm = NSFileManager.defaultManager () //Fetch Application Support Directory lar URLer = fm.URLsForDirectory (.ApplicationSupportDirectory, inDomains: .UserDomainMask) la applicationSupportDirectory = URLer [(URLs.count - 1)] //Oppretter program Stores Directory la URL = applicationSupportDirectory.URLByAppendingPathComponent ("Stores") hvis fm.fileExistsAtPath (URL.path!) {gjør {//Opprett Directory for Stores prøve fm.createDirectoryAtURL! (URL, withIntermediateDirectories: true, attributter: null)} catch {la createError = feil som NSError print ("\\ (createError), \\ (createError.userInfo)")}} avkastning URL}

Hvis vedvarende butikken koordinator er i stand til å legge den eksisterende vedvarende butikken på URLPersistentStore, flytter vi den vedvarende butikken til en egen katalog. For å gjøre det, bruker vi to hjelpemetoder, applicationIncompatibleStoresDirectory () og nameForIncompatibleStore (). Gjennomføringen av applicationIncompatibleStoresDirectory () er lik som applicationStoresDirectory ()
privat func applicationIncompatibleStoresDirectory () - >.; NSURL {la fm = NSFileManager.defaultManager () //Oppretter program Uforenlig Stores Directory la URL = applicationStoresDirectory (). URLByAppendingPathComponent ("Inkompatibel") hvis fm.fileExistsAtPath! (URL.path!) {Gjør {//Opprett Directory for Stores prøv fm.createDirectoryAtURL (URL, withIntermediateDirectories: true, attributter: null)} catch {la createError = feil som NSError print ("\\ (createError), \\ (createError.userInfo)")}} avkastning URL}

I nameForIncompatibleStore (), vi generere et navn for den inkompatible butikken basert på gjeldende dato og tid for å unngå å navngi kollisjoner
privat func nameForIncompatibleStore () - >.; String {//Initial Dato Atter la dateFormatter = NSDateFormatter () //Konfigurer Dato Atter dateFormatter.formatterBehavior = .Behavior10_4 dateFormatter.dateFormat = "åååå-MM-dd-HH-mm-ss" return "\\ (dateFormatter.stringFromDate (NSDate . ())) sqlite "}
Trinn 3: Lage en ny Vedvarende Butikk

Det er på tide å lage en ny vedvarende butikken for å fullføre oppsettet av kjernedata stabelen. De neste par linjer bør se veldig kjent nå
gjøre {//Erklærer Valg la alternativer = [NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true]. //Legg Vedvarende Store til Vedvarende Butikk koordinator prøve persistentStoreCoordinator.addPersistentStoreWithType (NSSQLiteStoreType, konfigurasjon: nil, URL: URLPersistentStore, alternativer: opsjoner)} fangst {la storeError = feil som NSError print ("\\ (storeError), \\ (storeError.userInfo)")}

Hvis kjernedata ikke er i stand til å skape en ny vedvarende butikk Da er det mer alvorlige problemer som ikke er relatert til datamodellen er uforenlig med den vedvarende butikken. Hvis du kjører inn i denne saken, og dobbeltsjekke verdien av URLPersistentStore

Trinn 4:. Varsle bruker:

Dette trinnet er trolig det viktigste når det gjelder å skape en brukervennlig søknad. Å miste brukerens data er en ting, men å late som om ingenting har skjedd er ikke hyggelig. Hvordan ville du føle hvis et flyselskap mistet bagasjen din, late som om ingenting har skjedd.
La storeError = feil som NSErrorprint ("\\ (storeError), \\ (storeError.userInfo)") //Update User Defaultslet userDefaults = NSUserDefaults. standardUserDefaults () userDefaults.setBool (sant, Forkey: "didDetectIncompatibleStore")

Hvis kjernedata var ikke i stand til å migrere vedvarende butikken med datamodellen, vi huske dette ved å sette en nøkkel-verdi-par i brukerstandarder database for programmet. Vi ser for denne nøkkelen-verdi-par i viewDidLoad () metoden i ViewController klassen
//MARK: -. //MARK: Vis Livet Cycleoverride func viewDidLoad () {super.viewDidLoad () gjør {prøve self.fetchedResultsController .performFetch ()} catch {la fetchError = feil som NSError print ("\\ (fetchError), \\ (fetchError.userInfo)")} la userDefaults = NSUserDefaults.standardUserDefaults () la didDetectIncompatibleStore = userDefaults.boolForKey ("didDetectIncompatibleStore") hvis didDetectIncompatibleStore {//Show Alert la applicationName = NSBundle.mainBundle (). objectForInfoDictionaryKey ("CFBundleDisplayName") la message = "En alvorlig programfeil oppstod under \\ (applicationName) prøvde å lese dine data. Vennligst kontakt support for å få hjelp." self.showAlertWithTitle ("Warning", melding: melding, cancelButtonTitle: "OK")}}

Gjennomføringen av showAlertWithTitle (_: melding: cancelButtonTitle :) er lik den vi har sett i AddToDoViewController. Merk at vi fjerner nøkkelverdi-par når brukeren kraner på knappen for varsling
//MARK: -. //MARK: Helper Methodsprivate func showAlertWithTitle (tittel: String, message: String, cancelButtonTitle: String) {//Initial Alert Controller la alertController = UIAlertController (tittel: tittel, melding: melding, preferredStyle: .Alert) //Konfigurer Alert Controller alertController.addAction (UIAlertAction (tittel: cancelButtonTitle, stil: .DEFAULT, handler: {(_) - > Void i Let userDefaults = NSUserDefaults.standardUserDefaults () userDefaults.removeObjectForKey ("didDetectIncompatibleStore")})) //Present Alert Controller presentViewController (alertController, animert: true, ferdigstillelse: null)}

Vi viser et varsel til brukeren , men det er en god idé å ta det noen skritt videre. For eksempel kan du oppfordre dem til å ta kontakt med support og du kan også implementere en funksjon som lar dem sende deg den korrupte butikken. Sistnevnte er svært nyttig for feilsøking av problemet

Trinn 5:. Testing

Vedvarende data er en viktig del av de fleste programmer. Det er derfor viktig å riktig teste det vi har implementert i denne artikkelen. For å teste vår utvinningsstrategi, kjører programmet i simulatoren og dobbeltsjekke at den vedvarende butikken ble opprettet i Application Support katalog, i Butikker
katalogen.
< p> Legg til en ny attributt til Element enhet i Ferdig 2.xcdatamodel Hotell og kjøre programmet en gang til. Fordi den eksisterende vedvarende butikken er nå uforenlig med datamodellen, er uforenlig vedvarende butikken flyttet til Ikke kompatibel
underkatalogen og en ny vedvarende butikken er opprettet. Du bør også se et varsel som informerer brukeren om problemet.

Konklusjon

Migrations er et viktig tema hvis du har tenkt å gjøre utstrakt bruk av grunndata. Migrations la deg trygt modifisere datamodell programmets og i tilfelle av lette vandringer, uten mye overhead.

I neste artikkel, fokuserer vi på subclassing NSManagedObject. Hvis en Core data prosjektet har noen form for kompleksitet, er da subclassing NSManagedObject veien å gå.