属性映射未正确关联。为什么? [英] property mapping not being associated correctly. Why?

查看:119
本文介绍了属性映射未正确关联。为什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

EDIT 1
虽然我理解对于这种特殊情况(以及其他类似情况),我可以单独使用映射编辑器来正确迁移我的存储,以便永久存储中的值跳过,但这不是解决我当前的问题,但只是避免解决问题的根本。我热衷于坚持我的自定义迁移策略,因为这将通过迁移过程给我带来很多控制,尤其是对于将来可能会设置自定义迁移策略的我来说。这是一个长期的解决方案,而不只是对于这种情况。



我敦促你尝试,帮助我解决目前的情况,而不是转移我到轻量级迁移或建议我避免使用迁移策略。非常感谢。



我真的很期待将这个问题排除在外,并提供您宝贵的意见和建议,帮助我解决这个问题。



我所做的:
我设置了迁移策略,以便源数据可以从复制到目标数据,版本1



这是迁移策略:

   - (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager错误:(NSError **)错误{

//创建产品托管对象
NSManagedObject * newObject = [NSEntityDescription insertNewObjectForEntityForName:[mapping destinationEntityName]
inManagedObjectContext: ];

NSString * productCode = [sInstance valueForKey:@productCode];
NSNumber * productPrice = [sInstance valueForKey:@productPrice];

[newObject setValue:productCode forKey:@productCode];
[newObject setValue:productPrice forKey:@productPrice];

//这是名称已更改的字段以及类型。
[newObject setValue:[NSNumber numberWithBool:YES] forKey:@productPriceNeedsUpdating];

//设置旧源产品和新目标之间的关联迁移管理器的产品
[manager associateSourceInstance:sInstance withDestinationInstance:newObject forEntityMapping:mapping];


/ *
测试语句,以确保目标对象包含正确的
值:正确的属性:

产品说明:< NSManagedObject:0xb983780> (entity:Product; id:0xb9837b0< x-coredata:/// Product / t97685A9D-09B4-475F-BDE3-BC9176454AEF6> ;; data:{
productCode = 9999;
productPrice =2.09 ;
productPriceNeedsUpdating = 1;
})
* /


//设置旧源产品和新目标之间的关联迁移管理器

return YES;
}

因此,即使测试的属性在运行时显示正确的值,



这是从数据存储的版本1到版本2的比较。



版本1:正确




https://i.stack.imgur.com/IofAC.pngalt =错误的字段中的错误值保存到数据库中>



输出应该将产品价格插入到 productPrice 字段中,而不是在 ProductPriceNeedsUpdating 字段中,实际上应该只有布尔值。
任何人都可以帮助我理解我在做什么错误,或解释这里发生了什么。



UPDATE 1 code>实体映射





更新2 - 20 / aug / 2014 01:02 GMT b

当我从版本1中删除 date 类型的 ProductPriceLastUpdated 版本2中的属性 ProductPriceNeedsUpdate 类型 boolean ,仅保留版本1和2中匹配的两个属性,一切工作。即使我可以离开这里,继续前进,我不能忽视当前使用版本1的数据库的用户,有没有无意义的 ProductPriceLastUpdated 属性,我需要类型转换为布尔值,并将名称更改为 ProductPriceNeedsUpdate 。当事情开始变得奇怪时,价格值显示在 ProductPriceNeedsUpdate 字段中,而不是 productPrice 字段。 / p>

我希望有人能解决原来的问题,告诉我为什么是entityMapping,或更多的属性映射没有被正确保存?



更新3 - 实体映射和属性

版本1



版本2



任何想法?

解决方案

首先,如果你只想使用一个轻量级的迁移(你真的应该在这种情况下)自定义迁移策略。在这种情况下,不需要。而且,事实上,你可以摆脱你的自定义映射模型。所有您需要做的是在您的版本2模型中,选择 productPriceNeedsUpdating 布尔标志,并在右侧的属性详细信息检查器中,将默认值设置为 YES



但是,如果您确实需要在自定义迁移策略的代码中编写此代码,我仍然不会使用自定义代码。您可以仅使用映射模型实现此迁移。只需选择ProductToProduct映射,并在productNeedsUpdating的值表达式中输入 YES 1



编辑



因此,经过相当冗长的屏幕共享,使用来自Marcus Zarra的Core Data书中的代码,描述逐渐迁移的商店。当写入时,WAL模式不是Core Data的默认模式。当启用WAL模式时,渐进式迁移存储不能正常工作,因为还有两个文件要处理,预写日志和共享内存文件。当简单地用一个新的存储替换旧的存储,而没有首先删除这些文件,奇怪的事情发生,如本文所述。解决方案最终最终是为逐渐迁移的方案禁用WAL模式,因此不会生成额外的文件。


EDIT 1 While I understand that for this particular scenario (and other alike) I could use the mapping editor alone to migrate my store correctly so that the values in the persistent store don't jump around, but that's not a solution to my current problem but only avoids addressing the root of the problem. I am keen on sticking with my custom migration policy as this will give me a lot of control through the migration process, especially for future scenarious where setting up a custom migration policy will work for me. This is for a long term solution and not just for this scenario.

I urge you to try and help me solve the current situation at hand rather than diverting me to lightweight migration or advising me to avoid using a migration policy. Thank you.

I really do look forward to sorting this out and your valuable input/ideas on what I could do to fix this problem.

What I have done: I have a migration policy set up so that the source data can be copied into the destination data from version 1 of the core model to version 2.

This is the migration policy:

- (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager error:(NSError **)error {

    // Create the 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 is the field where the name has changed as well as the type.
    [newObject setValue:[NSNumber numberWithBool:YES] forKey:@"productPriceNeedsUpdating"];

    // Set up the association between the old source product and the new destination Product for the migration manager
    [manager associateSourceInstance:sInstance withDestinationInstance:newObject forEntityMapping:mapping];


    /* 
  A test statement to make sure the destination object contains the correct
    values int he 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 up the association between the old source product and the new destination Product for the migration manager

    return YES;
}

So even though the tested properties show the correct values in runtime, the resultant values saved in the data model store is incorrect as seen in the snapshots.

Here is a comparison from version 1 to version 2 of the data store.

Version 1: Correct

to Version 2: Which is now storing the values incorrectly.

The expected output should have the Product price inserted into the productPrice field and not in the ProductPriceNeedsUpdating field which should actually only have boolean values. Can anyone help me understand what I am doing wrong, or explain whats happening here?

UPDATE 1 - Here are my entity mappings:

Update 2 - 20/aug/2014 01:02 GMT

When I remove the attribute ProductPriceLastUpdated of type date from version 1, and remove the attribute ProductPriceNeedsUpdate of type boolean in version 2, leaving only the two attributes that both match in version 1 and 2, then everything works. Even though I can leave it here and move on, I cant ignore the users that are currently using version 1 of the database which does have that pointless ProductPriceLastUpdated attribute which I need the type converted to boolean and also have the name changed to ProductPriceNeedsUpdate. Thats when things start going weird, and the price values are shown in the ProductPriceNeedsUpdate field instead of the productPrice field.

I hope someone can address the original problem and tell me why it is that the entityMapping, or more so, property mapping is not being saved properly?

Update 3 - EntityMapping and properties:

Version 1

Version 2

Any ideas?

解决方案

First, if you want to just use a lightweight migration (which you really should in this case) you can get rid of your custom migration policy. In this instance, it's not needed. And, as a matter of fact, you can get rid of your custom mapping model as well. All you need to do is in your Version 2 model, select the productPriceNeedsUpdating boolean flag, and in the Attribute Detail inspector on the right, set the default value to YES. This will achieve the goal you're try to get to with your custom migration policy.

However, if you really need to write this in code with your custom migration policy, I would still not use custom code. You can achieve this migration with only a mapping model. Simply select the ProductToProduct mapping, and in the value expression for productNeedsUpdating, enter YES, or 1.

EDIT

So, after a rather lengthy screen share, it was determined that the migration was using code from Marcus Zarra's Core Data book describing progressively migrating stores. When this was written, WAL mode was not the default mode with Core Data. When WAL mode is enabled, progressively migrating stores don't function well since there are two more files to deal with, the Write Ahead Log, and the Shared Memory file. When simply replacing the old store with a new one, without first removing those files, odd things happen, such as described in this post. The solution ultimately ended up being to disable WAL mode for the progressively migrating scenario so the extra files are not generated in the first place.

这篇关于属性映射未正确关联。为什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆