2013-03-12 9 views
9

Nella mia app, sto utilizzando Core Data insieme a un database sqlite aggiuntivo che non utilizza i dati principali. In questo database aggiuntivo, ho colonne che memorizzano i riferimenti alle istanze NSManagedObject tramite ogni istanza NSManagedObjectID.Utilizzo di una forma concisa di URI NSManagedObjectID?

sto ottenendo di objectId come una stringa per l'archiviazione in questo modo un'istanza:

instance.objectID.URIRepresentation.absoluteString 

Questo si traduce in una stringa che assomiglia a:

x-coredata://EE13EA1E-D5F4-4E38-986D-3F4B0B03AEE4/ClassName/p658 

cui posso poi usare per andare a prendere il NSManagedObject esempio come questo:

[persistentStoreCoordinator managedObjectIDForURIRepresentation:[NSURL URLWithString:uriString]]; 

come questi UR Le stringhe sono prolisse e contengono informazioni ridondanti, vorrei solo salvare l'aspetto unico di ciascuna al fine di conservare spazio nel db e migliorare le prestazioni della query. Quindi nell'esempio sopra, solo '658' piuttosto che l'intera stringa URI.

Quindi la prima domanda è: qual è un buon modo per estrarre solo la coda univoca di un NSManagedObjectID? E in secondo luogo, una volta memorizzato, come posso usarlo successivamente per recuperare l'istanza?

Vorrei evitare la manipolazione delle stringhe perché mi sembra icky, ma lo prenderò in considerazione se è l'unico modo. La mia unica confusione è dove la parte 'EE13EA1E-D5F4-4E38-986D-3F4B0B03AEE4' proviene dall'esempio precedente. Come posso accedere a quel valore per ricostruire un URI valido?

+0

Questo sembra essere un codice hash. In realtà è piuttosto brillante da parte di Core Data: 4 livelli di entropia mantengono gli oggetti univoci – CodaFi

+0

Inoltre, perché non unire i due database in uno solo? Il codice hash di un determinato oggetto gestito non è mai direttamente compatibile con nessun altro tipo di archivio (perché è soggetto a modifiche a seconda che l'oggetto sia un errore/è stato scritto sul disco) – CodaFi

+0

Vorrei poter fare tutto in Core Dati, ma ho dovuto dividere il db up per ottenere prestazioni accettabili su una grande operazione di sincronizzazione che è fondamentale per la funzionalità delle app.La suddivisione di una grande porzione di dati in sqllite raw da Core Data ha reso l'importazione 3-4 volte più veloce. Si presume che gli oggetti siano stati salvati sul disco. Nessun difetto in queste circostanze. – Dane

risposta

13

Si potrebbe provare a impostare il flag "Consente memoria esterna" sugli attributi che contengono i blocchi di dati di grandi dimensioni e vedere se ciò elimina la necessità di un database separato gestito direttamente.

Altrimenti, URIRepresentation restituisce un NSURL, quindi non è necessaria alcuna manipolazione di stringa "icky". Basta usare i metodi NSURL. ; ^) Ecco come si scomposizione:

NSURL *instanceURL = instance.objectID.URIRepresentation; 
NSURL *classURL = [instanceURL URLByDeletingLastPathComponent]; 
NSString *classString = [classURL absoluteString]; 
NSString *instanceId = [instanceURL lastPathComponent]; 

Ed ecco come si è messo di nuovo insieme dopo:

NSURL *reconstructedClassURL = [NSURL URLWithString:classString]; 
NSURL *reconstructedInstanceURL = [reconstructedClassURL 
    URLByAppendingPathComponent:instanceId]; 
NSManagedObjectID *objectID = [moc.persistentStoreCoordinator 
    managedObjectIDForURIRepresentation:reconstructedInstanceURL]; 
NSManagedObject *reconstructedInstance = [moc objectWithID:objectID]; 

Nota che, poiché il URIRepresentation è documentata per essere "archiviabile", non c'è nulla di male nella ricostruzione di uno dai componenti che ti sono stati dati da Core Data. Core Data non sa che l'hai smontato e rimesso insieme.

Tuttavia, Apple può modificare il formato restituito da URIRepresentation in futuro, purché managedObjectIDForURIRepresentation: continui ad accettare il formato precedente. Ciò significa che il codice di cui sopra si rompe lo URIRepresentation potrebbe smettere di funzionare un giorno.

+0

Grazie per la risposta. Penso che farò qualcosa di molto simile a questo, anche se non avrò la stringa di classe a meno che non la metta in NSPrefs o qualcosa del genere, dal momento che non voglio memorizzarla in ogni riga. Ma sembra basato sul commento di Martin R. sopra, che posso riassemblare l'URL usando i metadati persistentStoreCoordinator insieme ad alcune riflessioni di classe. Un po 'più complesso di quanto vorrei, ma sembra che dovrebbe funzionare bene. – Dane

Problemi correlati