• 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: Two questions about CoreData migration
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two questions about CoreData migration


  • Subject: Re: Two questions about CoreData migration
  • From: Quincey Morris <email@hidden>
  • Date: Fri, 22 Aug 2008 16:27:17 -0700

On Aug 22, 2008, at 12:14, Timothy Larkin wrote:

The first question is a simple one. After migration, the old persistent store is renamed sourceURL~.xml, and the document is supposed to open with a new persistent store with the old url, sourceURL.xml,. However, the document window that appears after migration has the title sourceURL~.xml, and saving this replaces the original, unmigrated document. Why doesn't the document open with sourceURL? I have examined the document at various stages during the open document process, and it consistently reports the URL without the tilde. And that is how the window initially appears. However, it switches to the form with the tilde as soon as the window is activated.

The second question is a bit more complicated. I have two entities with a one-to-many parent-child relationship. Say the parent is an entity named Parent. This is an abstract class; only Parent subclasses are instantiated. In the data model, the destination of the child to parent relationship is the abstract Parent class.

When I create a mapping model, there is no entity mapping for the Parent class automatically, I suppose because it is abstract. I can't compile the mapping model if there is no property mapping for the child to parent relationship. So I create an entity mapping for the abstract class Parent, and make a property mapping for the relationship using this mapping.

But when the model is migrated, the Parent mapping is never used, I suppose because there are no Parent entities. So that destinationInstancesForEntityMappingNamed:@"Parent" is empty for any child instance when the relations are being recreated. But it gets even stranger. I created a new migration policy class, MyPolicy, and assigned it as the custom policy for the child entity mapping. This class overrides only createRelationshipsForDestinationInstance. When this is called for a child instance, the child initially has a parent; but after executing super's createRelationshipsForDestinationInstance, the parent relationship is gone, which is consistent with there being no destination instances.

So what I've done is to save the parent, call the super method, and then restore the parent. This fixes the problem, but seems rather desperate. What is the correct method for dealing with a property mapping that involves an abstract class?

The first question came up on the list about a week ago. If you migrate during readFromURL:ofType:error: (or whatever), the NSPersistentDocument already exists, and it points to the old file. The actual migration is a core data function, so at the end of migration, when files are renamed, the NSPersistentDocument knows nothing of it and sticks with the old file.


There might be a way of re-pointing the NSPersistentDocument at the new file after the migration, but AFAIK Apple hasn't documented it. (It might be as simple as calling setFileURL: with the original file URL immediately after the migration.)

One alternative is to subclass NSDocumentController to override openDocumentWithContentsOfURL:display:error: and this technique is described in http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdImporting.html#/ /apple_ref/doc/uid/TP40003174-SW2, under the subheading "Document Based Example". In this case, you migrate the store first, outside the context of a document object, then open the NSPersistentDocument with the migrated file.

Regarding the second question, I believe it was stated on this list a few months ago that migration doesn't support abstract entities. However, I do have this working (to preserve existing parent/child relationships during the migration, not to change them), although I'm not sure I remember precisely what I did.

IIRC, I created the useless abstract entity mapping like you did. If you look at the parent and child properties listed for the concrete classes, you'll see that they'll then show as using this mapping. I think I just changed the relationship name popup to the correct one for the parent or child, and repeated that for each concrete entity. There was no need for a custom migration policy.

HTH



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Two questions about CoreData migration
      • From: Timothy Larkin <email@hidden>
References: 
 >Two questions about CoreData migration (From: Timothy Larkin <email@hidden>)

  • Prev by Date: Re: File Extensions Problem
  • Next by Date: Getting the active web page edit field for a WebView
  • Previous by thread: Two questions about CoreData migration
  • Next by thread: Re: Two questions about CoreData migration
  • Index(es):
    • Date
    • Thread