• 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: Versioning and CoreData
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Versioning and CoreData


  • Subject: Re: Versioning and CoreData
  • From: Uli Kusterer <email@hidden>
  • Date: Tue, 2 May 2006 12:11:20 +0200

Am 01.05.2006 um 21:49 schrieb Ondra Cada:
Haven't tested myself (caveat!), but I am comparatively positive this is something which just happens to work with XML (for that is essentially a bunch of NSDictionaries and you can ask a dictionary for a non-existing key, and get a valid nil), but does not with SQL (for you can't ask for a non-existing column).

Thanks, I was afraid so, but hadn't gotten around to trying this out yet.


Ryan Britton wrote:
I'm assuming by "model formats" you mean model versions and not persistent store formats?

Yup, sorry for the fuzziness.

When the migrator runs, it steps through each entity type. A new object for each object of this entity type is created in the new context. If it's set to copy old attributes, it does so. Every attribute that exists in the same form in both the old and new models is copied directly.

While creating the new objects, it also builds an (old object id) - > (new object id) mapping. A second stage rebuilds relationships using this mapping.

Great solution to a horrible problem. Is there no way to have CoreData do the copying based on the model file and just add the model's default values for any new items? I had hoped there was an easier way for the migration.


The final stage iterates over a series of callbacks, which are set prior to migration using this method:
- (void)setCallback:(SEL)aSelector forEntityName:(NSString *) anEntityName withVersionChange:(MSVersionChange *)aVersionChange
For each object of the specified entity, the selector will be called if the version change matches. The selector takes an old and new object and returns a BOOL indicating success or failure.


This currently has a few limitations. Namely, it does not support an entity type disappearing. If that happens, it will ignore the old objects of that entity type and will not attempt to migrate them. If you're at all interested, I'm more than willing to share the code though it is still a work in progress and not necessarily ready for every scenario.

I may get back to you on that. I just got swamped in more work, but once that's done I'd love to give it a try. Maybe I can somehow get the info from the model file and automate the migration step some more with the defaults in there.


Cheers,
-- M. Uli Kusterer
http://www.zathras.de


_______________________________________________ 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: Versioning and CoreData
      • From: Ryan Britton <email@hidden>
References: 
 >Versioning and CoreData (From: Uli Kusterer <email@hidden>)
 >Re: Versioning and CoreData (From: Ondra Cada <email@hidden>)

  • Prev by Date: Re: Refactoring tools available for Cocoa / ObjC?
  • Next by Date: Re: NSWindowController Subclassing - windowDidLoad Method
  • Previous by thread: Re: Versioning and CoreData
  • Next by thread: Re: Versioning and CoreData
  • Index(es):
    • Date
    • Thread