Re: Core Data migration and non-optional transient relationships

[Dave Fernandes]

During migration you have a bare NSManagedObject and not your custom subclass. 
So any custom code has to be in a migration policy.

Sent from my iPhone

> On May 20, 2014, at 12:07 PM, Mike Abdullah  wrote:
> 
> 
>> On 20 May 2014, at 15:21, Sean McBride  wrote:
>> 
>> Hi all,
>> 
>> Doing a Core Data migration (not the lightweight kind) I hit an error at the 
>> end:
>> 
>> "foo is a required value."
>> 
>> the 'foo' relationship it complains about is transient and so not present in 
>> the store.  Normally, I recreate the relationship in awakeFromFetch, but it 
>> doesn't seem to call that during migration.  As a test I made the 
>> relationship optional, then it no longer complains.
>> 
>> This seems to mean that transient relationships must always be optional?!  
>> At least if you ever want to migrate.  That seems odd.  Am I missing 
>> something here?
> 
> How about -awakeFromInsert? During a migration, new objects are being 
> created, based on the existing ones. Thus -awakeFromInsert gets called on 
> them rather than -awakeFromFetch.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration and non-optional transient relationships

[Jerry Krinock]

On 2014 May 20, at 07:21, Sean McBride  wrote:

> As a test I made the relationship optional, then it no longer complains.

Consider leaving it that way, Sean.  The only effect I’ve ever had from setting 
Core Data properties to be non-optional is the creation of mysterious errors 
and exceptions like this during build-ups and tear-downs.  If you need stuff 
validated in your data model, write your own code to do it, in places where you 
can make an appropriate recovery.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration and non-optional transient relationships

[Mike Abdullah]

On 20 May 2014, at 15:21, Sean McBride  wrote:

> Hi all,
> 
> Doing a Core Data migration (not the lightweight kind) I hit an error at the 
> end:
> 
> "foo is a required value."
> 
> the 'foo' relationship it complains about is transient and so not present in 
> the store.  Normally, I recreate the relationship in awakeFromFetch, but it 
> doesn't seem to call that during migration.  As a test I made the 
> relationship optional, then it no longer complains.
> 
> This seems to mean that transient relationships must always be optional?!  At 
> least if you ever want to migrate.  That seems odd.  Am I missing something 
> here?

How about -awakeFromInsert? During a migration, new objects are being created, 
based on the existing ones. Thus -awakeFromInsert gets called on them rather 
than -awakeFromFetch.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration: how to delete some managed objects?

[Sean McBride]

On Tue, 5 Mar 2013 18:56:32 -0800, Jerry Krinock said:

>> I take it you are using your technique successfully in practice?
>
>Maybe not.  I'd pasted in some of my code but modified it for your
>case.  Although I have done a lot of stuff in that method, I'm not sure
>if I have ever used that specific technique of *not* invoking super, to
>"delete" an object.  

OK, well, it seems to be working well at least!

>If you invoked associateSourceInstanc
>e:withDestinationInstance:forEntityMapping: per the documentation, you'd
>pass nil for destinationInstance.  And then it will either (1)
>degenerate internally to a no-op, (2) raise an exception, or (3) crash. 
>You can figure it out from there :)

As I said in my previous post, it goes boom. :(  I'll just not invoke super, it 
seems the right stuff is happening...

Thanks!

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration: how to delete some managed objects?

[Jerry Krinock]

On 2013 Mar 05, at 14:25, Sean McBride  wrote:

> I take it you are using your technique successfully in practice?

Maybe not.  I'd pasted in some of my code but modified it for your case.  
Although I have done a lot of stuff in that method, I'm not sure if I have ever 
used that specific technique of *not* invoking super, to "delete" an object.  

If you invoked 
associateSourceInstance:withDestinationInstance:forEntityMapping: per the 
documentation, you'd pass nil for destinationInstance.  And then it will either 
(1) degenerate internally to a no-op, (2) raise an exception, or (3) crash.  
You can figure it out from there :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration: how to delete some managed objects?

[Sean McBride]

On Mon, 4 Mar 2013 22:17:44 -0800, Jerry Krinock said:

>This is easy to do with a mapping model, migration policy and migration
>manager.  In your NSMigrationManager subclass implementation, implement
>an override something like this…
>
>- (BOOL)createDestinationInstancesForSourceInstance:
>(NSManagedObject*)oldInstance

Thanks Jerry,

I've been playing with this today and it looks promising.  I remember looking 
at it before but being scared off by the comment in the docs "If you override 
this method and do not invoke super, you must invoke NSMigrationManager’s 
associateSourceInstance:withDestinationInstance:forEntityMapping: to associate 
the source and destination instances as required" which I took to mean that I 
*had to* create a destination instance.  (Passing nil for 
'withDestinationInstance:' goes poof.)  I take it you are using your technique 
successfully in practice?

Thanks,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration: how to delete some managed objects?

[Jerry Krinock]

Correcting the message I just sent, wherever I mentioned subclassing 
NSMigrationManager, I meant subclassing NSMigrationPolicy.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration: how to delete some managed objects?

[Jerry Krinock]

On 2013 Mar 04, at 14:38, Sean McBride  wrote:

> What's a good way to delete some managed objects from a store when migrating 
> the store from version x to version y?  Basically, for entity 'Foo', I'd like 
> for instances that match predicate 'bar' to not exist in the new store.

This is easy to do with a mapping model, migration policy and migration 
manager.  In your NSMigrationManager subclass implementation, implement an 
override something like this…

- 
(BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject*)oldInstance
  entityMapping:(NSEntityMapping*)inMapping

manager:(NSMigrationManager*)inManager
  error:(NSError**)error_p {
  BOOL ok = YES ;
  NSError* error = nil ;
  NSEntityDescription *sourceInstanceEntity = [oldInstance entity] ;
  NSString* sourceInstanceEntityName = [sourceInstanceEntity name] ;
  if ([sourceInstanceEntityName isEqualToString:constEntityNameStark]) {
// Here's your predicate…
if ([oldInstance valueForKey:constKeyWhatever] passes the predicate) {
  ok = [super createDestinationInstancesForSourceInstance:oldInstance
entityMapping:inMapping
  manager:inManager
error:&error] ;
}
else {
  // Don't want this object in the new store.  Do nothing!
}
  }   

  if (error && error_p) {
*error_p = error ;
  }

  return ok ;
}

You can tweak destination instances by getting with 
-destinationInstancesForEntityMappingNamed:sourceInstances:.  But be careful to 
send only NSManagedObject messages to the source and destination instances.  
Although you think of them as your old MyBazManagedObject, remember they're 
not.  Don't use -myProperty.  Use -valueForKey:@"myProperty".

You can literally re-make your whole data model by subclassing 
NSMigrationManager.  Merge entities, make new relationships, whatever your 
marketing department desires :)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration, what to do when adding the nth version of your model?

[Jerry Krinock]

On 2012 Apr 04, at 16:40, Sean McBride wrote:

> How do I update my existing .xcmappingmodels to point to version 4 instead of 
> 3?
> 
> When viewing the xcmappingmodel in Xcode 4, should I use the 'destination' 
> popup and change it from 3 to 4?  After doing so, and diffing its 
> xcmapping.xml, I see the "destinationmodelpath" changes in the expecting way, 
> and one big blob also changes. h, scary.

I don't know if that would work or not.  In Xcode 3, there is a menu item…

   Design ▸ Data Model ▸ Update Destination Model

which is probably necessary to do.  You'll have to find where it got moved to 
in Xcode 4.

> Thanks for any help,

Now that you've got 4 versions you need to test 3 mapping models :(  A couple 
years ago I wrote a class which, instead, migrates serially until it reaches 
the current version.  Really old documents take a long time to migrate, but I 
feel that's a fitting punishment for users who have been lax in updating.  It's 
exciting to watch it grind for 2 minutes and then succeed.  Another 
disadvantage is that my code digs into the .momd bundle's VersionInfo.plist and 
reads some key/values, which is unsupported as far as I know.  But I've never 
had any trouble with it.

https://github.com/jerrykrinock/ClassesObjC/blob/387db9d380fc78c86bb87b61cfa165d53f6bb5ab/SSYPersistentDocumentMultiMigrator.h

Also, it has some dependencies on other sources which you'd have to dig out of 
my github.  Maybe someone else has published a better implementation.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Dave Fernandes]

I'm not using autosave. In fact this is done in my document controller before 
the NSPersistentDocument is even created. Does the Core Data stack have some 
awareness of an autosave mode? Perhaps, as you suggest, Apple has dropped this 
feature and this is just a documentation bug. Hope someone from Apple can 
comment on whether this is the case.

On 2011-08-01, at 1:08 AM, Jerry Krinock wrote:

> 
> On 2011 Jul 31, at 21:18, Dave Fernandes wrote:
> 
>> I just found a strange thing on Lion: the backup~ file doesn't get produced 
>> with in-place lightweight migration. The same binary *does* create the 
>> backup~ file on Snow Leopard, though. Has anyone else noticed this?
> 
> Have not noticed it because I use my own migration code.  If you are using 
> Auto Save, though, there would be no need for the ~ files since they should 
> be available in Versions browser, so it would make sense that Apple drop this 
> "feature".
> 
> I definitely wouldn't consider it much of a loss, though.  The only thing 
> those ~ files have done for me is to confuse users.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Jerry Krinock]

On 2011 Jul 31, at 21:18, Dave Fernandes wrote:

> I just found a strange thing on Lion: the backup~ file doesn't get produced 
> with in-place lightweight migration. The same binary *does* create the 
> backup~ file on Snow Leopard, though. Has anyone else noticed this?

Have not noticed it because I use my own migration code.  If you are using Auto 
Save, though, there would be no need for the ~ files since they should be 
available in Versions browser, so it would make sense that Apple drop this 
"feature".

I definitely wouldn't consider it much of a loss, though.  The only thing those 
~ files have done for me is to confuse users.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Dave Fernandes]

I just found a strange thing on Lion: the backup~ file doesn't get produced 
with in-place lightweight migration. The same binary *does* create the backup~ 
file on Snow Leopard, though. Has anyone else noticed this?


On 2011-07-21, at 8:31 AM, Roland King wrote:

> I suppose I had to get to core data migration one day … :(
> 
> I've read the documentation a couple of times and it says that the default 
> migration process finishes by renaming the old store to the same thing with a 
> tilde prefix. Does that mean you, the programmer, are responsible for 
> deleting it again afterwards or is there a piece I've missed where eventually 
> it does get cleaned up? I was thinking that if you use automatic migration, 
> you don't even know when the store has been migrated and that you should thus 
> go look for a tilde version and remove it. If that's the case I wondered how 
> many apps have upgraded their core data stores and left the old one sitting 
> there taking up the same amount of space. 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Dave Fernandes]

On 2011-07-21, at 12:16 PM, Roland King wrote:

> Great - thanks for this - gets me started, I've found the documentation quite 
> dense and soon I have to pitch in and just give it a go (I have a model I 
> need to update in my test app and I really don't want to toss the data). 
> 
> I need to hunt around the NSManagedObjectModel class a bit more, clearly, 
> there are methods there I don't know enough about. I assume there are ways to 
> enumerate the models in the bundle, figure out which one is the 'current'

+[NSManagedObjectModel mergedModelFromBundles:]

> one and which one may match the store

+[NSManagedObjectModel mergedModelFromBundles:forStoreMetadata:]

> , will go read the class docs when they've finished d/l'ing. I saw some of 
> the methods for making an on-the-fly migration, I'll try those out too see if 
> they work. 
> 
> I think lightweight is going to do it for this change. One attribute deleted, 
> one entity added, one mapping added, one attribute added (with a  default). 
> It's not a bad way to get my feet wet with migration actually, I can afford 
> to bungle it up, I can save the sqlite file before I start and give it few 
> cracks. Ok that's the weekend!

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Roland King]

Great - thanks for this - gets me started, I've found the documentation quite 
dense and soon I have to pitch in and just give it a go (I have a model I need 
to update in my test app and I really don't want to toss the data). 

I need to hunt around the NSManagedObjectModel class a bit more, clearly, there 
are methods there I don't know enough about. I assume there are ways to 
enumerate the models in the bundle, figure out which one is the 'current' one 
and which one may match the store, will go read the class docs when they've 
finished d/l'ing. I saw some of the methods for making an on-the-fly migration, 
I'll try those out too see if they work. 

I think lightweight is going to do it for this change. One attribute deleted, 
one entity added, one mapping added, one attribute added (with a  default). 
It's not a bad way to get my feet wet with migration actually, I can afford to 
bungle it up, I can save the sqlite file before I start and give it few cracks. 
Ok that's the weekend!

On Jul 21, 2011, at 9:35 PM, Dave Fernandes wrote:

> Yes, if you want the file deleted you have to do it yourself. There are 
> certainly cases where you would not want to delete the file. For example for 
> a document, the user may want to keep that archive around in case they need 
> to revert to a previous version of the app, or share it with someone else. In 
> that case, they should be informed when the file is going to be migrated, and 
> they should be the one to delete the old version.
> 
> You can check whether the store needs to be migrated using 
> -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]; first 
> get the current model and then check whether it is compatible with metadata 
> from the store you want to open.
> 
> Lightweight migration also cannot handle all types of model changes. So, when 
> you start to support multiple model versions, it might be a good idea to 
> check if you *can* migrate from version x to version y using +[NSMappingModel 
> inferredMappingModelForSourceModel:destinationModel:error:]. You may end up 
> with cases where you have to use your own mapping model for some migrations.
> 
> Dave
> 
> On 2011-07-21, at 8:31 AM, Roland King wrote:
> 
>> I suppose I had to get to core data migration one day … :(
>> 
>> I've read the documentation a couple of times and it says that the default 
>> migration process finishes by renaming the old store to the same thing with 
>> a tilde prefix. Does that mean you, the programmer, are responsible for 
>> deleting it again afterwards or is there a piece I've missed where 
>> eventually it does get cleaned up? I was thinking that if you use automatic 
>> migration, you don't even know when the store has been migrated and that you 
>> should thus go look for a tilde version and remove it. If that's the case I 
>> wondered how many apps have upgraded their core data stores and left the old 
>> one sitting there taking up the same amount of space. 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
>> 
>> This email sent to dave.fernan...@utoronto.ca
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.org

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Dave Fernandes]

Yes, if you want the file deleted you have to do it yourself. There are 
certainly cases where you would not want to delete the file. For example for a 
document, the user may want to keep that archive around in case they need to 
revert to a previous version of the app, or share it with someone else. In that 
case, they should be informed when the file is going to be migrated, and they 
should be the one to delete the old version.

You can check whether the store needs to be migrated using 
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]; first get 
the current model and then check whether it is compatible with metadata from 
the store you want to open.

Lightweight migration also cannot handle all types of model changes. So, when 
you start to support multiple model versions, it might be a good idea to check 
if you *can* migrate from version x to version y using +[NSMappingModel 
inferredMappingModelForSourceModel:destinationModel:error:]. You may end up 
with cases where you have to use your own mapping model for some migrations.

Dave

On 2011-07-21, at 8:31 AM, Roland King wrote:

> I suppose I had to get to core data migration one day … :(
> 
> I've read the documentation a couple of times and it says that the default 
> migration process finishes by renaming the old store to the same thing with a 
> tilde prefix. Does that mean you, the programmer, are responsible for 
> deleting it again afterwards or is there a piece I've missed where eventually 
> it does get cleaned up? I was thinking that if you use automatic migration, 
> you don't even know when the store has been migrated and that you should thus 
> go look for a tilde version and remove it. If that's the case I wondered how 
> many apps have upgraded their core data stores and left the old one sitting 
> there taking up the same amount of space. 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration Error

[Jerry Krinock]

On 2011 Jan 16, at 17:31, Michael Link wrote:

> This migration is using the default mapping model created in Xcode. The Event 
> entity was changed to have an abstract parent entity, before it stood alone.

Migrating abstract entities can be problematic.  For example,

http://www.cocoabuilder.com/archive/cocoa/227970-migration-with-abstract-entities.html?q=Core+data+abstract+entity+migration+error#227970

> I tried creating an entity migration policy subclass but none of its methods 
> are called. Anyone have any ideas what the problem might be?

Maybe you have not specified the migration policy in the Custom Policy: field 
of the relevant "Entity" form of the Mapping Model.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration : Splitting an Entity : Source Fetch ?

[Jerry Krinock]

On 2010 Sep 13, at 15:38, Jerry Krinock wrote:

> …I found that Xcode accepted my input if I set "Source Fetch" to Default and 
> entered one of these as "Filter Predicate":
> 
>($source.beak != nil)  // Bird
>($source.beak == nil)  // Fish

Upon studying my situation a little further, I realized that my Birds and Fish 
also needed to be moved to a different managed object context.  (Yup, some 
serious database rework.)  Since Xcode's mapping model editor can't do that, I 
had to delete these Entity Mappings, and instead implement them in code 
(NSEntityMigrationPolicy) where, of course, it worked.

Maybe next time.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration

[Chaitanya Pandit]

Oh sorry, forgot to 'reply all'
my bad.

Thanks,
Chaitanya Pandit
Expersis Software Inc.

On Dec 22, 2009, at 7:12 PM, Jerry Krinock wrote:

> 
> On 2009 Dec 21, at 23:16, Chaitanya Pandit wrote:
> 
>> Hi jerry,
>> I think what i'll have to do is if the user closes the doc without saving, 
>> just replace the new someDoc with ~someDoc and delete the ~someDoc so that 
>> it can still be opened by the older app,
> 
> So you are getting the tilde docs.  That's good.
> 
>> as my older app doesn't know how to deal with the ~ thing
> 
> I'm disappointed that Apple did not build that ingelligence in, as I had 
> postulated:
> 
>> On Dec 22, 2009, at 7:26 AM, Jerry Krinock wrote:
> 
>>> Also, I've never tried to open such a migrated document with an earlier app 
>>> version, but it would make sense that the earlier version would look for 
>>> and automatically load the old tilde document if it couldn't load the 
>>> current document due to model changed.
> 
> I don't see why it wouldn't do that for you.  You should file a bug.  
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration

[mmalc Crawford]

On Dec 20, 2009, at 11:40 pm, Chaitanya Pandit wrote:

> One weird thing that is happening is that just after the 
> "configurePersistentStoreCoordinatorForURL..." call, the contents of my 
> document on the disk are changed, even if i didn't save the document
> 
It's not clear in what sense this is "weird"?  This is expected behaviour...

On Dec 21, 2009, at 5:56 pm, Jerry Krinock wrote:
> But something else should happen, which is that, if the filename is, for 
> example,  SomeDoc.myapp, the original file will be copied to SomeDoc~.myapp.  
> Note the tilde.
> I've never seen this documented anywhere, though.
> 
"If the migration proceeds successfully, the existing store at storeURL is 
renamed with a “~” suffix before any file extension and the migrated store 
saved to storeURL."


mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration

[Jerry Krinock]

On 2009 Dec 20, at 23:40, Chaitanya Pandit wrote:

> I'm working on the migration for one of my Core Data document based 
> application
> 
> One weird thing that is happening is that just after the 
> "configurePersistentStoreCoordinatorForURL..." call, the contents of my 
> document on the disk are changed ... i can no longer open that document in 
> 1.0 as it has changed the data and it throws an alert saying the version of 
> the model has been changed

But something else should happen, which is that, if the filename is, for 
example,  SomeDoc.myapp, the original file will be copied to SomeDoc~.myapp.  
Note the tilde.

I've never seen this documented anywhere, though.  Also, I've never tried to 
open such a migrated document with an earlier app version, but it would make 
sense that the earlier version would look for and automatically load the old 
tilde document if it couldn't load the current document due to model changed.

I recently had alot of trouble with Core Data migration, and saw alot of crap, 
but never saw a migration occur without the tilde doc appearing.  If you figure 
out how you broke it, let us know.  I'm worried that I might need to know 
someday ;)

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration from xml to sqlite

[Adam Swift]

On Sep 2, 2009, at 4:51 AM, Ian Kennedy wrote:


Hi all,

How would I go about doing a one-time migration of application data  
from an xml persistent store to a sqlite persistent store? i.e. the  
model stays the same, the data is migrated, and the app uses the  
sqlite store from there on out.


I've been unsuccessfully trying to do it inside of the  
persistentStoreCoordinator method by working with the example from  
here: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingPersistentStores.html


Here is what I've tried, which doesn't migrate any data, just  
provides me with an empty sqlite store:


http://pastie.textmate.org/602152



NSPersistentStore *xmlStore = [persistentStoreCoordinator  
persistentStoreForURL:xmlUrl];
NSPersistentStore *sqliteStore = [persistentStoreCoordinator  
migratePersistentStore:xmlStore toURL:sqliteUrl options:nil  
withType:NSSQLiteStoreType error:&error];


persistentStoreCoordinator = [[NSPersistentStoreCoordinator  
alloc] initWithManagedObjectModel: [self managedObjectModel]];


persistentStoreCoordinator is nil when you attempt the migration.

Code defensively!  You should be checking that he xmlStore is non-nil  
before attempting migration, that the sqliteStore is non nil after  
migration and presenting the error if one occurs.



Thanks for any help,
Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/aswift%40apple.com

This email sent to asw...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration and the Inexperienced Younger Self

[I. Savant]

On Thu, May 7, 2009 at 1:19 PM, Adam Swift  wrote:

> Unless you are specifying NSIgnorePersistentStoreVersioningOption as an
> option to addPersistentStoreWithType:...

  I'm not.


> ... if there are any changes to your
> data model that would result in changes to the data that is persisted
> ... your version hashes should be
> different between a version 1 data model and a version 2 data store file,
> and that should result in a NSPersistentStoreIncompatibleVersionHashError
> (134100).

  Agreed. Hence my post. :-)


> No, unless you're project was configured with a 10.4 deployment target
> (check your project and target build settings)

  As I mentioned previously, both version 1 and version 2 of this
application are linked against 10.5. This has been verified
thoroughly.

  So ... something's definitely wrong here.

--
I.S.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration and the Inexperienced Younger Self

[Adam Swift]

On May 7, 2009, at 7:02 AM, I. Savant wrote:

On Wed, May 6, 2009 at 6:36 PM, Melissa J. Turner  
 wrote:



Context is important. Also future-proofing.

If your app was originally written against v1 CoreData (Tiger),   
you need to
update the app to be wise enough to check the store's metadata and  
run away,

run away from any store containing unexpected values (ie version hash
information). v1 CoreData always assumes that it can open a store  
it was

told to open until later evidence proves otherwise; later versions of
CoreData realized that was perhaps an unwise decision, and added  
the current
versioning and migration infrastructure. Due to binary  
compatibility issues,
applications compiled on Tiger will continue to exhibit the old  
behavior.

There's a general discussion of migration under 10.4 at
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdZ104Versioning.html#//apple_ref/doc/uid/TP40002989


 Thanks, but I think I should clarify things a bit more succinctly:

1 - Version 1 of the app and data model were *started* on Tiger (I
created the project and worked on it under 10.4 for awhile).
2 - Later, when Leopard was released, I began linking against the 10.5
SDK and making use of some Leopard hotness.
3 - Version 1 of the app (and data model) was released as full-on
10.5-compiled and is 10.5-required (ie, has not been run on Tiger by
any users).
4 - Version 2 of the app and data model have a working automatic
migration for the very first change - the simple addition of a float
attribute to a single entity.

 The problem is that version 1 of the app will open version 2 data
files without complaint. This is unexpected and - I dare say - wrong.

Unless you are specifying NSIgnorePersistentStoreVersioningOption as  
an option to addPersistentStoreWithType:..., if there are any changes  
to your data model that would result in changes to the data that is  
persisted (adding/removing transients, validation rules, etc don't  
count because it doesn't change the data stored externally), your  
version hashes should be different between a version 1 data model and  
a version 2 data store file, and that should result in a  
NSPersistentStoreIncompatibleVersionHashError (134100).



 A question: Could my having created the project under Tiger, then
later linking against 10.5 have caused this problem? In other words,
is the 10.4 version of the xcdatamodel still 10.4-limited when
compiled by momc, even when targeting 10.5?

No, unless you're project was configured with a 10.4 deployment target  
(check your project and target build settings)



 In any case, sorry for the previous wordy-confusion. That'll teach
me to wax poetic in my posts. ;-)

--
I.S.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/aswift%40apple.com

This email sent to asw...@apple.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration and the Inexperienced Younger Self

[I. Savant]

On Wed, May 6, 2009 at 6:36 PM, Melissa J. Turner  wrote:

> Context is important. Also future-proofing.
>
> If your app was originally written against v1 CoreData (Tiger),  you need to
> update the app to be wise enough to check the store's metadata and run away,
> run away from any store containing unexpected values (ie version hash
> information). v1 CoreData always assumes that it can open a store it was
> told to open until later evidence proves otherwise; later versions of
> CoreData realized that was perhaps an unwise decision, and added the current
> versioning and migration infrastructure. Due to binary compatibility issues,
> applications compiled on Tiger will continue to exhibit the old behavior.
> There's a general discussion of migration under 10.4 at
> http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdZ104Versioning.html#//apple_ref/doc/uid/TP40002989

  Thanks, but I think I should clarify things a bit more succinctly:

1 - Version 1 of the app and data model were *started* on Tiger (I
created the project and worked on it under 10.4 for awhile).
2 - Later, when Leopard was released, I began linking against the 10.5
SDK and making use of some Leopard hotness.
3 - Version 1 of the app (and data model) was released as full-on
10.5-compiled and is 10.5-required (ie, has not been run on Tiger by
any users).
4 - Version 2 of the app and data model have a working automatic
migration for the very first change - the simple addition of a float
attribute to a single entity.

  The problem is that version 1 of the app will open version 2 data
files without complaint. This is unexpected and - I dare say - wrong.

  A question: Could my having created the project under Tiger, then
later linking against 10.5 have caused this problem? In other words,
is the 10.4 version of the xcdatamodel still 10.4-limited when
compiled by momc, even when targeting 10.5?

  In any case, sorry for the previous wordy-confusion. That'll teach
me to wax poetic in my posts. ;-)

--
I.S.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Missing EOF (Was Re: Core Data Migration and the Inexperienced Younger Self)

[Sam Krishna]

Dear Apple Developer Engineering Team (Dev Support, Dev Tools, Core  
Data, and anyone else who works for Matt Firlik):


I miss Enterprise Objects Framework for the Desktop. Badly.

I know the Objective-C codebase is sitting somewhere in an old CVS or  
Subversion repository deep in the bowels of WebObjects engineering. I  
know there are many things about EOF that don't work for stand-alone  
application development that just needs *one* persistent data store,  
but damn, it sure was sexy and it worked really great and it had about  
10 years of battle-hardening before it was deprecated and it's spirit  
went on to live in the Java EOF frameworks with Java WebObjects.


And I totally respect everything bbum and all the other Core Data  
developers have done over the last 5 years to make Core Data usable.  
And it is. With all of its warts, it is. Otherwise, we wouldn't use it.


I would just like to ask you all in Framework Engineering to  
*consider* bringing it back and modernizing it for this era, and  
merging the best of Core Data with the best of EOF to create something  
truly spectacular. "The Enterprise" is now willing to listen to Apple  
in a way it wasn't before the iPhone. It would be really great if some  
of the goodness that earned the full measure of devotion by Apple's  
defunct Enterprise Consulting Unit (Apple Enterprise Software) was  
brought back out of storage and made available for the next generation  
of developers who want to do something interesting, but don't want to  
use SQLLite. You don't need to answer this here... and I'm clear this  
list is not advocacy (Scott, no need to respond), but I just wanted to  
ask you, the Apple Engineering gods, to consider thawing Objective-C  
EOF out of deep storage and make it something that can really sing for  
the modern era of data-driven software applications.


Thank you for listening.

Live Playfully,

Sam
-
If he listens in faith,
finding no fault, a man is free
and will attain the cherished words
of those who act in virtue.

On May 6, 2009, at 6:36 PM, Melissa J. Turner wrote:


Context is important. Also future-proofing.




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Migration and the Inexperienced Younger Self

[Melissa J. Turner]

Context is important. Also future-proofing.

If your app was originally written against v1 CoreData (Tiger),  you  
need to update the app to be wise enough to check the store's metadata  
and run away, run away from any store containing unexpected values (ie  
version hash information). v1 CoreData always assumes that it can open  
a store it was told to open until later evidence proves otherwise;  
later versions of CoreData realized that was perhaps an unwise  
decision, and added the current versioning and migration  
infrastructure. Due to binary compatibility issues, applications  
compiled on Tiger will continue to exhibit the old behavior. There's a  
general discussion of migration under 10.4 at http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdZ104Versioning.html#//apple_ref/doc/uid/TP40002989


Later versions of CoreData always check the store metadata for version  
hash information, which is affected by things that could change the  
schema (adding and removing entities and/or persistent properties,  
adding or removing validation rules, etc), but not by things that  
don't change the schema (adding or removing transient properties,  
adding or removing default values). For more details, see the Core  
Data Model Versioning and Data Migration Programming Guide, and for a  
concrete discussion of what affects version hashes, the section on  
versioning (http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmVersioning.html#//apple_ref/doc/uid/TP40004714-SW1 
).


An application controlled technique would be to add an application  
specific piece of metadata (a version # perhaps) to your stores, and  
have your various application versions categorically refuse to open a  
store whose app version is >= the version it knows how to read. This  
can allow for a better user experience than the default  
NSPersistentStoreIncompatibleVersionHashError returned by  
addPersistentStore, which is a bit vague about which newer version of  
the application you need to buy to open a given file.


Cheers,
+Melissa






___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core data migration question

[mmalc Crawford]

On Apr 7, 2009, at 12:28 PM, Timothy Larkin wrote:

I think that Jon is asking whether he should give a version number  
to his data model, and not whether he should create a second version  
of his data model. If this is in fact his question, then I think the  
answer is yes, because this will make it easier, if he needs to  
migrate at some time in the future, to identify which data model  
version he migrating from.



Again, no.


You don't need to specify a version number for the previous model,  
Core Data ignores it:


	


"As a developer, your perspective is typically that a version is  
denoted by an identifier—a string or number, such as “9A218”, “2.0.7”,  
or “Version 1.1”. [...]
Core Data, on the other hand, treats these identifiers simply as  
“hints”."


In particular:

"Notice that Core Data ignores any identifiers you set. In the  
examples above, Core Data treats version 1.0 (Figure 1) and 1.1  
(Figure 2) as being compatible."




You typically don't need to retrieve the source model yourself:

"If your application does support versioning and you choose to use the  
default migration process, you simply use  
addPersistentStoreWithType:configuration:URL:options:error: as  
described in “The Default Migration Process.” The fundamental  
difference from the non-versioned approach is that you instruct the  
coordinator to automatically migrate the store to the current model  
version by adding an entry to the options dictionary where the key is  
NSMigratePersistentStoresAutomaticallyOption and the value is an  
NSNumberobject that represents YES."







Even if you do want to initiate migration yourself, you ask Core Data  
to find the source model:




NSManagedObjectModel *sourceModel =
[NSManagedObjectModel mergedModelFromBundles:bundlesForSourceModel
forStoreMetadata:sourceMetadata];



mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core data migration question

[Timothy Larkin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I think that Jon is asking whether he should give a version number to  
his data model, and not whether he should create a second version of  
his data model. If this is in fact his question, then I think the  
answer is yes, because this will make it easier, if he needs to  
migrate at some time in the future, to identify which data model  
version he migrating from.


On Apr 7, 2009, at 2:41 PM, mmalc Crawford wrote:



On Apr 7, 2009, at 10:53 AM, Jon Munson II wrote:

I wasn't certain if, in order to utilize versioning later, that I  
would need to mark the current model in some way.  The Apple dox  
didn't state one way or another, and I didn't wish to make an  
assumption and find out later that I missed some important step  
which would result in hours of headache.


It's not clear how the discussion indicates there would be "hours of  
heartache"?


"The versioned model has a new runtime format (.momd) that is a  
bundle containing individually compiled .mom files. You load  
the .momd model just as you would a regular .mom file (using  
NSManagedObjectModel’sinitWithContentsOfURL:).
To create a versioned model, you start with a normal model such as  
that illustrated in Figure 4."







It would certainly be trivial to test.



mmalc


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/tsl1%40cornell.edu

This email sent to t...@cornell.edu


Tim Larkin
Network Administrator Emeritus
E&EB
Cornell University



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknbqXgACgkQOzculQ5SMWRVnwCfb8lsg+3BnPfPGSb5AbJd0Sec
xxgAoL92cNyz+ElgUC3PQo2M44pzTBa2
=azsg
-END PGP SIGNATURE-
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core data migration question

[mmalc Crawford]

On Apr 7, 2009, at 10:53 AM, Jon Munson II wrote:

I wasn't certain if, in order to utilize versioning later, that I  
would need to mark the current model in some way.  The Apple dox  
didn't state one way or another, and I didn't wish to make an  
assumption and find out later that I missed some important step  
which would result in hours of headache.


It's not clear how the discussion indicates there would be "hours of  
heartache"?


"The versioned model has a new runtime format (.momd) that is a bundle  
containing individually compiled .mom files. You load the .momd model  
just as you would a regular .mom file (using  
NSManagedObjectModel’sinitWithContentsOfURL:).
To create a versioned model, you start with a normal model such as  
that illustrated in Figure 4."







It would certainly be trivial to test.



mmalc


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core data migration question

[Jon Munson II]

I wasn't certain if, in order to utilize versioning later, that I  
would need to mark the current model in some way.  The Apple dox  
didn't state one way or another, and I didn't wish to make an  
assumption and find out later that I missed some important step which  
would result in hours of headache.


On Apr 7, 2009, at 1:46 PM, mmalc Crawford wrote:



On Apr 7, 2009, at 9:34 AM, Jon C. Munson II wrote:

One thing I cannot readily determine from the documents is whether  
one
should begin with a "versioned" model.  By "begin" I mean the model  
is
versioned from the start as opposed to later in the application's  
life

cycle.
So, my question is:  is it better to create (start with) a  
versioned model
to better facilitate the probable incidence of migration to a newer  
model

later?


Short answer: No.

Why would you do that?  In what way do you anticipate that it would  
facilitate support for versioning in the future?
If you only have a single version, there's no point in creating a  
versioned model -- you'd simply create a new version and then have  
to delete it.


mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/jmunson%40his.com

This email sent to jmun...@his.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core data migration question

[mmalc Crawford]

On Apr 7, 2009, at 9:34 AM, Jon C. Munson II wrote:


One thing I cannot readily determine from the documents is whether one
should begin with a "versioned" model.  By "begin" I mean the model is
versioned from the start as opposed to later in the application's life
cycle.
So, my question is:  is it better to create (start with) a versioned  
model
to better facilitate the probable incidence of migration to a newer  
model

later?


Short answer: No.

Why would you do that?  In what way do you anticipate that it would  
facilitate support for versioning in the future?
If you only have a single version, there's no point in creating a  
versioned model -- you'd simply create a new version and then have to  
delete it.


mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data migration

[Timothy Larkin]

Having worked through this problem myself, I can offer a few  
suggestions. First, some kind list member pointed out to me that the  
automated migration function does not support abstract classes. So you  
have to outwit Apple.


I created a custom migration policy for the abstract class by  
subclassing NSEntityMigrationPolicy. This gave me a way to look at  
what was happening. The abstract class, HMPart had a one-to-many  
relationship with a concrete class, HMInput. Call one of the concrete  
subclasses of HMPart HMThing. When the migration process came to  
createRelationshipsForDestinationInstance for an instance of HMInput,  
the to-one relationship to the instance of HMThing had already been  
correctly instantiated; that is, there was an instance of HMThing on  
the far side of the relationship. But when  
createRelationshipsForDestinationInstance was exectued, the HMThing  
instance was tossed out and replaced by nil, because the migrator did  
not know how to create an instance of HMPart. So the migrator did the  
right thing, and then screwed it up.


This observation led me to write the following, which is called by the  
migrator with the child instance, e.g. an instance of HMInput, as  
"dInstance". The method merely saves the parent object, calls the  
super method (which destroys the parent object), and finally restores  
the parent. You might think that you could dispense with the super  
method, since you are just undoing what the super method did. But it  
seems that the super method does other things that actually are  
necessary.


- (BOOL)createRelationshipsForDestinationInstance:(NSManagedObject  
*)dInstance
	entityMapping:(NSEntityMapping *)mapping 	manager: 
(NSMigrationManager *)manager

 error:(NSError **)error
{
id part = [dInstance valueForKey:@"part"];
	BOOL result = [super  
createRelationshipsForDestinationInstance:dInstance

entityMapping:mapping
manager:manager
error:error];
[dInstance setValue:part forKey:@"part"];
return result;
}

This successfully worked around the problem.

--
Timothy Larkin
Abstract Tools
Caroline, NY



PGP.sig
Description: This is a digitally signed message part
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Core Data migration

[Paul Collins]

Back on March 29 2008, Mr. Wilson reported a problem with migration  
that I seem to be having now. To wit, a core data model that includes  
an abstract entity and entity inheritance fails to be migrated on OS X  
10.5.


I'm getting different errors than he reported. I created a mapping  
model from the previous to the new data model. Finding, as Mr. Wilson  
did, a empty property mapping involving an abstract entity, I created  
a mapping for the abstract entity and related the property mapping to  
it.


When I attempt automatic migration  
(NSMigratePersistentStoresAutomaticallyOption), I get "Persistent  
store migration failed, missing mapping model." Alternatively, when I  
manually select the mapping model, NSMappingModel  
mappingMOdelFromBundles:forSourceModes:destinationModel: does give me  
my mapping model, but migrateStoreFromURL returns an NSError:  
Domain=NSCocoaErrorDomain Code=134110 UserInfo=0x80e25b0 "An error  
occured during persistent store migration."


If there's a workaround for this, I'd sure love to hear it.

Best regards,

Paul Collins
Gracion Software


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Core Data Migration Progress

[Doug Penny]

On Thu, Sep 11, 2008 at 8:02 PM, Adam Swift <[EMAIL PROTECTED]> wrote:

> No, you'll need to do a manual migration so you can register yourself as an
> observer of the NSMigrationManager's migrationProgress

Thanks Adam, I figured that was the case.  I didn't want to spend much
time on this feature so I decided to test the data store for
compatibility and if it needs to be migrated I pop up a window with an
indeterminate progress indicator that is displayed until
-addPersistentStoreWithType:configuration:URL:options:error: is
returned.

Doug
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Core Data Migration Progress

[Adam Swift]

On Sep 11, 2008, at 8:08 AM, Doug Penny wrote:


I have a core data store that I am migrating using the
default/automatic migration process.  It seems to work very smoothly,
but takes a minute or two to complete.  I would like to provide some
type of feedback to the user to let them know what is going on and
possibly a progress indicator.  Is this possible using the basic
default migration progress?  I noticed that NSMigrationManager has a
migrationProgress method, but I don't think I have access to this when
using the automatic migration.

No, you'll need to do a manual migration so you can register yourself  
as an observer of the NSMigrationManager's migrationProgress



Sincerely,
Doug Penny
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/aswift%40apple.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

re: Core Data migration

[Ben Trumbull]

David,


To sum up:
Relationships to entities from which another entity inherits are not
automatically set up properly.


Unfortunately.  This is a known issue.


Anyone have any experience with this, or know how to handle this
situation? I suppose I could write a whole bunch of custom code to
handle it, but it seems as if the migration system should handle the
inheritance.


I'll trade you a bug report for a work around.
--

-Ben
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]