Core Data unsigned long long 最佳实践答案

【问题标题】：Core Data unsigned long long best practiceCore Data unsigned long long 最佳实践
【发布时间】：2014-09-23 14:14:06
【问题描述】：

我需要将uint64_t 号码存储在Core Data 属性中。我还需要在谓词中使用此属性。
问题是，Core Data 只有 Integer64 类型，我无法对该属性执行 fetch 请求。
例如：

    NSNumber *pid = @(9224992848802061623ULL); // some unsigned long long  

    // create a person with this id     
    Person *person = [NSEntityDescription insertNewObjectForEntityForName:@"Person" inManagedObjectContext:self.context];
    person.personId = pid; // personId is core data NSNumber property typed integer 64

    [self.context save:nil];

    // now try to fetch this person we just added
    NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"Person"];
    request.predicate = [NSPredicate predicateWithFormat:@"personId == %@", pid];  

    NSArray *match = [self.context executeFetchRequest:request error:nil];
    // NO RESULTS!

正如您在此处看到的，当我尝试获取与我刚刚创建的相同的 personId 时，我没有得到任何结果。
我认为问题在于 Core Data 将其存储为已签名，因此值不同，但我该如何解决呢？

那么排序呢？假设我想要一个也按 personId 排序的获取请求？现在发生的事情是大数字变为负数（因为它们被视为已签名），因此它们排序到列表的开头。

那么处理 unsigned long long 和 Core Data 时的最佳实践是什么？

【问题讨论】：

标签： ios objective-c core-data unsigned unsigned-long-long-int

【解决方案1】：

我建议使用NSDecimalAttributeType 存储这些。那应该能够支持任何64位数字并正确排序。

或者，您可以将它们存储为二进制数据，因为可能它们或多或少是不透明的标识符。

【讨论】：

你能解释一下使用十进制时发生了什么吗？它似乎有效，但我不明白为什么
@Eyal 它将值存储为 NSDecimalNumber，它本质上是具有 38 位精度的 base-10 数字。因此，对于 64 位无符号整数来说，空间绰绰有余。