Migrazione dei dati principali su più aggiornamenti di versione

Ho un'app per iPhone che utilizza i dati principali.Migrazione dei dati principali su più aggiornamenti di versione

Ho fatto un aggiornamento e ho utilizzato la migrazione leggera per passare da V1 a V2 del mio MOM (Managed Object Model). Questo ha funzionato perfettamente.

Cosa succede quando voglio andare a V3 (e oltre) della mia mamma?

Se decido di continuare con leggero migrazione, si è trattare automaticamente con la migrazione da V1 a V3 e V2 a V3 di mia mamma, o devo fare qualcosa in più?
Se decido di utilizzare un modello di mappatura, cosa succede? Come posso gestire l'aggiornamento di V1 e V2 da MOM a V3? Devo creare un modello di mappatura per V1 a V3 e V2 a V3?
Questa domanda va oltre ... cosa succede quando ho V6 MOM e devo ancora supportare la possibilità di eseguire l'aggiornamento da un MOM V1?

Un'altra domanda è qual è il modo migliore per determinare la versione della MOM corrente? Dovrei usare isConfiguration: compatibleWithStoreMetadata:

Grazie per qualsiasi assistenza. Mi piacciono i Core Data. Ma a volte mi fa girare la testa e mi confondo, ed è per questo che cerco un po 'di saggezza.

fonte

2009-10-12 thevoid

Sono andato con la migrazione ordinaria utilizzando createDestinationInstancesForSourceInstance.
Il frammento mostra come sovrascrivere quel metodo e come ottenere la sourceVersion del modello da migrare. La migrazione effettiva si sta verificando nella classe helper TZMigrationHelper.

- (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager error:(NSError **)error 
{ 
    float sourceVersion = [[[mapping userInfo] valueForKey:@"sourceVersion"] floatValue]; 
    if(sourceVersion <= 0.9) 
    { 
     mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"someProperty"]; 
     mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"anotherProperty"]; 
     mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"oneMoreProperty"];  
    } 
    return [super createDestinationInstancesForSourceInstance:sInstance entityMapping:mapping manager:manager error:error]; 
}

fonte

2009-10-13 07:55:36

Da un'occhiata più ravvicinata al documento Apple CoreDataVersioning.pdf, si afferma che il processo di migrazione "Prova a trovare un modello di mappatura che mappa dal modello a oggetti gestito per lo store esistente a quello in uso dal coordinatore di archivio permanente. " Ciò implica che ho bisogno di creare un numero crescente di modelli di mappatura per ogni giro del mio database. Quindi, per V3, avrei bisogno di un modello di mappatura da V1 a V3 e di un modello di mappatura da V2 a V3. Quindi, sono confuso dalla tua logica "fall through" e dal motivo per cui è necessaria. – thevoid

Hai provato se è sufficiente definire più modelli da migrare su più versioni? Penso che rimuoverò l'approccio fall-over di cui sopra, anche se non sono sicuro che sia necessario. –

La rilevazione iniziale era ormai molti mesi fa, ma penso che la migliore risposta si trova nel libro Core Data di Marcus Zarra (o on-line negli esempi di codice). Google per "progressivelyMigrateURL" e uno troverà il codice per iterare progressivamente attraverso i modelli - il che consentirebbe di creare associazioni dal modello n al modello n + 1, senza preoccuparsi dell'esplosione combinatoria per la creazione di mappature tra tutti gli accoppiamenti di modelli.

Ciò potrebbe comportare una migrazione più lenta in fase di esecuzione. Non ho indagato su questo.

fonte

2010-05-17 16:49:40 westsider

È decisamente più lento in fase di esecuzione rispetto alla possibilità di passare direttamente da v1 a v15. Tuttavia, il test delle prestazioni aiuterà a determinare se la mia migrazione progressiva funzionerà o se sarà necessario eseguire tutte le mappe. –

Il codice sorgente con il metodo progressivelyMigrateURL proviene dal libro Pragmatic Bookshelf "Dati principali". Il link è qui: http://pragprog.com/titles/mzcd/source_code – bentford

Il codice di Macrus Zarra è ottimo e consiglio vivamente il suo libro su Core Data. Detto questo, ho dovuto apportare la seguente modifica ad esso per evitare che si ripetesse all'infinito se scopre i file '.mom' nell'ordine sbagliato: [gist.github.com/2321704](http://gist.github.it/2321704) (senza questo, c'è la possibilità che continui a provare a migrare alla stessa versione che è già attiva, PER SEMPRE.) –

Migrazione dei dati principali su più aggiornamenti di versione

risposta

Problemi correlati