• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData issue when updating a file format
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData issue when updating a file format


  • Subject: Re: CoreData issue when updating a file format
  • From: mmalcolm crawford <email@hidden>
  • Date: Fri, 6 May 2005 19:52:34 -0700

On May 6, 2005, at 1:07 PM, Jim Correia wrote:

On May 6, 2005, at 1:12 PM, mmalcolm crawford wrote:


On May 6, 2005, at 8:27 AM, Bruno Blondeau wrote:


I'm trying to open a CoreData/SQLite document which was saved with a v1 model. I'm getting an error, while it is working fine with the XML data store (which automatically adds the needed columns for the v2 model).
File formats are not backwards compatible. If you change the schema (model), you cannot read old files.
Is there a capsule summary of how this situation should be handled?

I hope Bill and Ben will forgive me forwarding these recent suggestions:


(1) Put a version number in the metadata of your stores. (Of course, the lack of a version number key being present is indicative of version 1. :)


(2) When opening the store, first grab the metadata and check the version #. You don't need a model (or even the type of the store) to grab the metadata.

- obviously, if the version # is the latest and greatest, open the store and run with it.

(3) If the version # is a previous version, then:

- grab the previous model
- initialize a Core Data stack with said model and store
- grab the latest and greatest model
- initialize a Core Data stack with the latest and greatest model and a new store
- fetch the objects out of the old store and populate the new store, mapping in between


It helps if the old model is modified-- this can be done in memory before the model is used, if you want-- such that it doesn't use any custom classes; simply loads all of the data as instances of NSManagedObject.

The end result of this is that it is a KVC mapping problem. "Instances of this entity become that entity. Attributes of this name become that name. Members of this relationship are added to that relationship. These new attributes are defaulted to these values. Etc."

[...]

How you traverse the model is entirely up to you. When doing this kind of object graph conversion, I typically do a traversal like:

- convert across all entities that are relatively standalone (i.e. things that are more or less select lists like categories or priorities or other items that typically show up in popups in the UI)

- create a old-global-id <-> new-global-id map as they are converted

- traverse the collection of "root" entities one by one, making new instances in the new model, converting as needed.

... etc ...

Non-trivial, yes. Tedious, yes. But migrating data models is typically hard.




Another approach:


You can iterate through your (old) model and grab the entities one by one. You can fetch all the objects for that entity (use a nil predicate, or TRUE)


In a different PersistentStoreCoordinator, you can create a new object, and then iterate through the attributes and relationships (as defined by the NSEntityDescription) making copies. "copying" a relationship will require creating a new managed object for the destination and filling in its properties. An NSDictionary mapping the objectIDs from the old store into the new objectIDs is how you'd handle the new IDs in the new store.

You should fetch everything into memory and convert it all at once. Alternative approaches will not be feasible for maintaining relationship integrity.



--

One variant I [mmalc] might suggest here -- you might also consider using model configurations instead of actual different models.

--

For a development cycle, if you need to update an existing store, another possibility is to use an XML store and apply an XSLT.

As someone earlier noted, if you use an XML file and simply add entities and properties, typically the store won't fail.




I hope this helps for now; I'll try to "streamline" this and get it published ASAP, but I'm afraid other things will take priority.


mmalc

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CoreData issue when updating a file format
      • From: T Reaves <email@hidden>
References: 
 >CoreData issue when updating a file format (From: Bruno Blondeau <email@hidden>)
 >Re: CoreData issue when updating a file format (From: mmalcolm crawford <email@hidden>)
 >Re: CoreData issue when updating a file format (From: Jim Correia <email@hidden>)

  • Prev by Date: Re: Core Data Question
  • Next by Date: Menu Item's Key Equivalents Affecting Other Item
  • Previous by thread: Re: CoreData issue when updating a file format
  • Next by thread: Re: CoreData issue when updating a file format
  • Index(es):
    • Date
    • Thread