【问题标题】:Why is this code raising the "CoreData: error: (19) PRIMARY KEY must be unique" error?为什么此代码会引发“CoreData:错误:(19)PRIMARY KEY 必须是唯一的”错误?
【发布时间】:2012-09-10 20:21:31
【问题描述】:

此代码引发“CoreData:错误:(19) PRIMARY KEY 必须是唯一的”错误。 Day 实体只有一个when 属性,即NSDate,以及一个称为tasks 的一对多关系。为什么会出现这个错误?如果已经存储了具有特定日期的Day,则获取它,否则我将其插入。因此,对于每个 day 对象,应该有一个不同的 when 属性。我不确定这是否是主键。如何解决这个问题?先感谢您。

   NSMutableSet *occurrences = nil;

   occurrences = ... 
   NSMutableOrderedSet *newSet = [NSMutableOrderedSet orderedSetWithCapacity:[occurrences count]];

   for(NSDate *current in occurrences) {

        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

        // try to find a corresponding Day entity whose when attribute is equal to the current occurrence
        // if none is available, create it

        Day * day = [[self getDayForDate:current inManagedObjectContext:moc] retain];
        if(!day){
            day = (Day *) [NSEntityDescription insertNewObjectForEntityForName:@"Day" inManagedObjectContext:moc];
        }

        day.when = current;
        [day addTasksObject:aTask];

        [newSet addObject:day];

        [moc insertObject:day];
        [moc processPendingChanges];

        [day release];

        [pool release];            
    } 

- (Day *)getDayForDate:(NSDate *)aDate inManagedObjectContext:(NSManagedObjectContext *)moc
{        
    NSFetchRequest *request = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Day" inManagedObjectContext:moc];
    [request setEntity:entity];
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(when == %@)", aDate];
    [request setPredicate:predicate];
    NSError *error = nil;
    NSArray *array = [moc executeFetchRequest:request error:&error];
    [request release];

    Day *theDay = nil;

    if(array && [array count] == 1){
        theDay = [array objectAtIndex:0];
    }

    return theDay;
}

【问题讨论】:

  • 我猜你不需要插入新的一天,如果你已经有了它(这是day 不为零的情况)。特别是我指的是[moc insertObject:day];。你为什么这样做?
  • 如果您使用insertNewObjectForEntityForName,该方法会在您保存 moc 时为您插入对象。如果您需要修改它(您已检索到非零日),请修改并保存。此外,我会在循环结束时执行processPendingChanges(仅出于性能原因)。
  • @Flex_Addicted,你是对的。现在 Day 对象被无条件插入。这大概就是问题的根源。我会验证这一点。但是,我无法在循环结束时保存,因为其他对象都在周围并且仍然需要编辑。我会让你知道的。
  • 第一条评论中的勘误表:为什么要使用它? 然后,如果无法保存,请将processPendingChanges 移动到 for 循环的末尾。祝你有美好的一天。
  • 好的,它现在按预期工作。吸取的教训:永远不要在深夜工作,现在看来这似乎微不足道(但不是今天晚上)。如果您将您的 cmets 改写为答案,我将很高兴接受它。再次感谢您。

标签: iphone ios ipad core-data


【解决方案1】:

我最近一直在为内部 iOS 应用程序的 CoreData: error: (19) PRIMARY KEY must be unique 错误而苦苦挣扎,幸运的是经过一两天的研究和代码修改后发现了解决方案,我想在这里分享我的发现,希望他们会对其他人有所帮助。

首先是一点背景

我们的内部应用程序最初从未使用任何代码来更新其 CoreData 存储 - 相反,当需要在应用程序中显示新数据时,对于每个应用程序构建迭代,CoreData SQLite 后备存储文件被简单地替换为使用基于桌面的标准 SQLite 编辑器编辑的新版本——即原始 SQLite 文件已根据需要进行修改和更新。虽然人们认识到这种方法没有考虑到 CoreData 的“黑盒”性质,但在过去几年中,它实际上在我们的简单应用程序中为我们提供了很好的服务,并且该应用程序很高兴地接受了更新后的 SQLite 文件。新应用构建。

但是,最近我们对应用程序进行了重大改革,从通过 Xcode 和应用程序重建更新应用程序资产和数据的模型转变为通过 Web 服务获取新应用程序数据的模型,而且是在PRIMARY KEY must be unique 问题出现的这项新开发工作。

经过几天的努力解决问题,认为新的CoreData实体创建代码(已经检查并重新检查)或其他相关问题一定有问题,通过进一步研究发现我能够使用 Xcode 为我们的应用程序启用 CoreData SQL 调试(按照this 非常有用的 SO 帖子中的说明)。

当我仔细研究 Xcode 中的 SQL 日志时,我可以看到,在 CoreData 每次调用 INSERT 之前,在 SQLite 后备存储中都有一条新记录,框架使用以下查询 @ 查询了 Z_PRIMARYKEY 表987654326@ 其中? 在幕后被相关CoreData 实体的相关Z_ENT 值替换(您可以通过查看Z_PRIMARYKEY 表的内容来查看每个CoreData 实体的Z_ENT 值)。这就是我终于明白 CoreData 的黑匣子里发生了什么的时候!然后,我在 Mac 上使用 Liya 应用程序仔细查看了我们应用程序的 SQLite 文件,并查看了Z_PRIMARYKEY 表的内容,果然Z_MAX 列值都设置为0。当 CoreData 首次为我们的应用程序生成空的 SQLite 后备存储文件时,它们的初始值从未更改过!

我立即意识到出了什么问题,以及 CoreData 报告主键错误的原因——它实际上与最初怀疑的任何更高级别的 CoreData 实体对象的属性冲突无关,但确实是低级错误。直到现在这个错误才变得绝对有意义,它一直存在,只是在正确的上下文中没有被理解。

进一步研究表明,我们的内部团队在过去几年中成功地直接编辑 SQLite 后备存储,插入、更新和删除各种实体表中的记录,但我们的团队从未对 Z_PRIMARYKEY 表进行了任何更改,并且由于我们的应用程序一直以只读方式使用 CoreData 的方式,这从来都不是问题。

但是,既然我们的应用程序正在尝试创建 CoreData 条目并将其保存回 SQLite 后备存储,因此生成的许多 INSERT 查询都失败了,因为 CoreData 无法获得正确的最大主数据库用于在任何给定表上生成下一个顺序主键的键值,因此INSERT 查询将失败,并出现现在可以理解的有意义的PRIMARY KEY must be unique 错误!

解决错误

我意识到每个开发人员可能会以各种方式为他们的应用程序生成默认/初始 CoreData 内容,但是,如果您曾经在 CoreData 中遇到过这个特定错误并且也很难立即找到明确的答案,我希望以下想法会有所帮助:

  • 我们的应用程序的 CoreData 后备存储是通过直接编辑 SQLite 文件(从实体表中插入、更新和删除记录)手动更新的 - 由于我们采用只读方式,这种方法已经工作了很长时间一直在我们的应用程序中使用这些数据。然而,这种方法未能真正认识到 CoreData 的抽象“黑盒”性质以及 SQLite 记录不等同于 CoreData 实体,SQLite 连接不等同于 CoreData 关系等事实。

    李>
  • 如果您的应用使用任何类型的预填充 CoreData 存储,并且如果您以任何方式而不是通过 CoreData 填充 SQLite 后备存储的内容,请确保如果您确实在您的任何CoreData 实体表,您还要确保更新Z_PRIMARYKEY 表中的相关记录,将Z_MAX 列值设置为相关实体表中的当前最大Z_PK 值。

    例如,如果您的 CoreData 中有一个名为 Employee 的 CoreData 实体 SQLite 持久存储后备文件,这将由一个名为 ZEMPLOYEE 的表表示 - 该表将包含一些“隐藏”CoreData 列,包括Z_PKZ_ENTZ_OPT 等,以及代表您实体的列 属性和关系。此实体表还将在 Z_PRIMARYKEY 表中具有相应的记录,其 Z_NAME 值为 Employee - 因此,当您将新记录直接添加到 ZEMPLOYEE 表时 - 确保在完成添加记录后,即您遍历每个实体表并将最大 Z_PK 值复制到 Z_PRIMARYKEY 表的 Z_MAX 列。你输入Z_MAX的值应该是对应表中最大的Z_PK值;不要将Z_MAX 设置为等于Z_PK + 1 的值,因为这不是CoreData 所期望的!

您可以使用以下SQL查询任意实体表的最大Z_PK值:

"SELECT Z_PK FROM ZEMPLOYEE ORDER BY Z_PK DESC LIMIT 1"

这将为您提供ZEMPLOYEE 表中任何记录的最大Z_PK 值 - 显然您应该将ZEMPLOYEE 替换为您应用数据模型的相关表名称。

对于我们的应用程序,我能够编写一个简单的命令行脚本,直接读取 SQLite 文件,遍历 Z_PRIMARYKEY 表的每条记录,并使用正确的 Z_MAX 值更新它。一旦完成,我就可以使用这个更新的文件作为应用程序的持久存储支持文件。现在,当我插入和保存新的 CoreData 实体时,一切正常。

现在我们的应用程序可以通过网络服务直接请求新数据,我们将完全摆脱手动编辑 SQLite 后备存储,而专门使用 CoreData 框架来更新数据,但有时或其他应用程序,可能需要这种快速简便的数据输入,我希望这个答案可以帮助其他开发人员,并节省他们发现这个解决方案所花费的时间和精力。

【讨论】:

  • 如果您将 Z_MAX 设置为 -1,那么在下一次插入表时,CoreData 将 1)根据已经存在的内容计算下一个 PK 应该是什么,以及 2)将 Z_MAX 更新为为您提供正确的价值。
  • 就我而言,我使用的是 SQLITE DATABASE BROWSER 2.0,它是一个非常简单的 Sqlite 数据库查看器和编辑器。它非常简单但非常有效。感谢@lanp。您的建议让我很快就能解决这个问题。
  • 从您的角度来看,是否可以通过使用 CoreData 方法或其他方式以编程方式将 Z_MAX 值更改为 -1?我需要在运行时进行,但我不知道该怎么做。
  • @Lisarien 如果您使用 CoreData API 来管理您的数据,则不需要重置 Z_MAX,如果 Apple 更改 API,依赖它可能会出现问题。我之前的回答是继承了一个没有有效使用 CoreData 的应用程序的结果。由于 CoreData 本身不提供操作 Z_MAX 的方法,因此您必须使用 sqlite3 框架直接针对您的 CoreData sqlite 数据库执行 SQL 查询。但是,我不建议将此作为长期策略,并且您需要小心确保在 CoreData 加载 sqlite 文件之前重置 Z_MAX 值。
【解决方案2】:

我想如果你已经有了一个新的Day,我想你不需要插入它(这是当 day 不是 nil 时的情况)。特别是我指的是[moc insertObject:day]

如果您使用insertNewObjectForEntityForName,该方法会在您保存 moc 时为您插入对象。如果您需要修改它(您已检索到非零日),请修改并保存。此外,我会在循环结束时执行processPendingChanges(仅出于性能原因)。

希望对您有所帮助。

【讨论】:

    猜你喜欢
    • 2012-11-01
    • 2023-04-01
    • 1970-01-01
    • 2020-03-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-07-09
    相关资源
    最近更新 更多