ios - property mapping not being associated correctly. Why? -
edit 1 while understand particular scenario (and other alike) use mapping editor alone migrate store correctly values in persistent store don't jump around, that's not solution current problem avoids addressing root of problem. keen on sticking custom migration policy give me lot of control through migration process, future scenarious setting custom migration policy work me. long term solution , not scenario.
i urge try , me solve current situation @ hand rather diverting me lightweight migration or advising me avoid using migration policy. thank you.
i forward sorting out , valuable input/ideas on fix problem.
what have done: have migration policy set source data can copied destination data version 1
of core model version 2
.
this migration policy:
- (bool)createdestinationinstancesforsourceinstance:(nsmanagedobject *)sinstance entitymapping:(nsentitymapping *)mapping manager:(nsmigrationmanager *)manager error:(nserror **)error { // create product managed object nsmanagedobject *newobject = [nsentitydescription insertnewobjectforentityforname:[mapping destinationentityname] inmanagedobjectcontext:[manager destinationcontext]]; nsstring *productcode = [sinstance valueforkey:@"productcode"]; nsnumber *productprice = [sinstance valueforkey:@"productprice"]; [newobject setvalue:productcode forkey:@"productcode"]; [newobject setvalue:productprice forkey:@"productprice"]; //this field name has changed type. [newobject setvalue:[nsnumber numberwithbool:yes] forkey:@"productpriceneedsupdating"]; // set association between old source product , new destination product migration manager [manager associatesourceinstance:sinstance withdestinationinstance:newobject forentitymapping:mapping]; /* test statement make sure destination object contains correct values int right properties: product description: <nsmanagedobject: 0xb983780> (entity: product; id: 0xb9837b0 <x-coredata:///product/t97685a9d-09b4-475f-bde3-bc9176454aef6> ; data: { productcode = 9999; productprice = "2.09"; productpriceneedsupdating = 1; }) */ // set association between old source product , new destination product migration manager return yes; }
so though tested properties show correct values in runtime, resultant values saved in data model store incorrect seen in snapshots.
here comparison version 1 version 2 of data store.
version 1: correct
to version 2: storing values incorrectly.
the expected output should have product price inserted productprice
field , not in productpriceneedsupdating
field should have boolean values. can me understand doing wrong, or explain whats happening here?
update 1 - here entity mappings
:
update 2 - 20/aug/2014 01:02 gmt
when remove attribute productpricelastupdated
of type date
version 1, , remove attribute productpriceneedsupdate
of type boolean
in version 2, leaving 2 attributes both match in version 1 , 2, works. though can leave here , move on, cant ignore users using version 1 of database have pointless productpricelastupdated
attribute need type converted boolean , have name changed productpriceneedsupdate
. thats when things start going weird, , price values shown in productpriceneedsupdate
field instead of productprice
field.
i hope can address original problem , tell me why entitymapping, or more so, property mapping not being saved properly?
update 3 - entitymapping , properties:
version 1
version 2
any ideas?
first, if want use lightweight migration (which should in case) can rid of custom migration policy. in instance, it's not needed. and, matter of fact, can rid of custom mapping model well. need in version 2 model, select productpriceneedsupdating
boolean flag, , in attribute detail inspector on right, set default value yes
. achieve goal you're try custom migration policy.
however, if need write in code custom migration policy, still not use custom code. can achieve migration mapping model. select producttoproduct mapping, , in value expression productneedsupdating, enter yes
, or 1
.
edit
so, after rather lengthy screen share, determined migration using code marcus zarra's core data book describing progressively migrating stores. when written, wal mode not default mode core data. when wal mode enabled, progressively migrating stores don't function since there 2 more files deal with, write ahead log, , shared memory file. when replacing old store new one, without first removing files, odd things happen, such described in post. solution ended being disable wal mode progressively migrating scenario files not generated in first place.
Comments
Post a Comment