Core Data learning note with Swi

2015-11-23 本文已影响306人扬仔360

CoreData Learning note

后续阅读：

https://www.objc.io/issue-4/core-data-overview.html
中文：http://www.cocoachina.com/ios/20130911/6981.html

01: 存取：

首先开头用最简单的小例子。

//MARK: - Save Data
  func saveName(name: String){
    let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
    let managedContext = appDelegate.managedObjectContext

    let entity = NSEntityDescription.entityForName("Person", inManagedObjectContext: managedContext)
    let person = NSManagedObject(entity: entity!, insertIntoManagedObjectContext: managedContext)

    person.setValue(name, forKey: "name")

    do {
      try managedContext.save()
      people.append(person)
    } catch let error as NSError{
      print("Could not save \(error),\(error.userInfo)")
    }
  }
  
  //MARK: - Fetch Data
  override func viewWillAppear(animated: Bool) {
    super.viewWillAppear(animated)

    let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
    let managedContext = appDelegate.managedObjectContext

    let fetchRequest = NSFetchRequest(entityName: "Person")
    do {
      let results = try managedContext.executeFetchRequest(fetchRequest)
      people = results as! [NSManagedObject]
    } catch let error as NSError {
        print("Could not fetch \(error), \(error.userInfo)")
    }
  }

02.

可以使用BinaryData来存储图像，但是巨大的图像直接存储在数据库中会导致性能降低，选择类型为BD的Attribute，然后可以在右边的属性选择框中勾选Allows External Storage，类似所以存储在外部，提高数据访问性能。

Transformable类型用于存储那些实现了NSCoding protocol 的对象，比如 UIColor，UIColor 实现了NSSecureCoding。

03. 不要过于依赖 NSManagedObject

虽然使用KVC很便捷，但是尽量不要过于依赖KVC。

04.自动创建Entity的子类：

打开。xcfatamodeld文件 -> Editor -> Create NSManagedObject Subclass

创建出来的每个 Entity 对应了两个文件，普通的文件仅仅包含了所有的 action 操作，Entity 的所有属性都用 extension 的方式进行了实现。所有的属性在Extension中声明的时候前面都加上了@NSManaged，这个标示通知了编译器，这个 property 会在runtime的时候提供，而不是在编译的时候。

一般的模式下，property 是由内存中的实例变量实现的，但是在managedObject中，是由managed object context实现的，compile time 并不知道。

创建了属于自定义的Entity的Managed Object的子类有两个好处：
· 隔离的KVC，编译器可以获取 Property，而不是通过 KVC 的方式，方便编写程序。
· 方便重写方法。当时注意Apple文档中标出了一些从来都不应该重写的方法。

05. 结合子类 NSManagedObject 去实现添加和 Retrieve 的 Demo：

这里也就是增加的Demo：

let bowtie = NSEntityDescription.insertNewObjectForEntityForName("Bowtie", inManagedObjectContext: managedObjectContext) as! Bowtie
    bowtie.name = "My bow tie"
    bowtie.lastWorn = NSDate()

    do {
      try managedObjectContext.save()
    } catch let error as NSError {
      print("Save error\(error.localizedDescription)")
    }

    //Retrieve test bow tie
    do {
      let request = NSFetchRequest(entityName: "Bowtie")
      let ties = try managedObjectContext.executeFetchRequest(request) as! [Bowtie]

      let sample : Bowtie = ties[0]
      print("Name = \(sample.name), Worn: \(sample.lastWorn)")
    }catch let error as NSError {
      print("Fetching error: \(error.localizedDescription)")
    }

06. Data Validation：

选择Entity的Property，然后右边可以设置该项属性的最大值、最小值和默认值。

07. 具体的操作对象：

具体这一部分可以添加常用的方法：会在后续添加。

http://justsee.iteye.com/blog/1881110

NSManagedObjectContext

表示被操作数据的上下文环境。类似于一种持续性的数据库连接，可以做增删查等操作。

而且只有在调用Save方法的时候，这些所有的改动才会被提交，否则是不会在持久层做任何改动的。

支持撤销和重做。

NSManagedObjectModel

表示被管理的数据模型，这里包含着所有对象的表格信息，所有数据结构，包括他们之间的关系。

在这里添加实体的属性，添加实体和实体之间的关系。

所以NSManagedObjectModel其实包含着NSEntityDescription和NSPropertyDescription，前者相当于数据库中的一个表，后者相当于表中的一列。NSPropertyDescription可以描述实体的基本属性（Attributes）、实体之间的关系（Relationships）还有查询属性（FetchedProperty）。

查询属性对应NSFetchedPropertyDescription对象。

Persistent Store

持久化存储层，是由文件或者外部数据库组成的，大多数情况下访问持久化层全部由上下文Context来完成。

CoreData 提供了四种持久化层的方案：

非原子访问的：NSQLiteStoreType
原子访问的：BSXMLStoreType、NSBinaryStoreType、NSInMemoryStoreType。

XML是将数据存为XML文件，只在 OS X 平台下可用。Binary的方法是存为一个Data文件。InMemory的方式是不会对数据进行真正意义上的持久化，全部存储在内存中，当应用程序退出时，数据也就消失了。

NSPersistentStoreCoordinator

持久化存储助理的存在相当于和数据持久层的连接器，SQLite的话就是和数据库的连接，它设置着数据库的路径名字、位置、存储方式和存储的时机。
CoreData其实就相当于一个栈，栈的底层是持久化存储层，栈顶是Context，所以一般简单的需求我们只需要使用栈顶的Context，那么NSPersistentStoreCoordinator就是栈中层的一层存在，协调上栈的上下层关系。

负责理解NSManagedObjectModel和去NSPersistentStore中执行相应操作。

补充NSManagedObjectContext

NSManagedObjectContext就像内存中的便签纸，临时修改你的ManagedObject，所以知道你提交save()，否则持久化层是不会有变化的。

上下文管理这Managed Object的生命周期，管理的同时提供了很多高级特征可以给以使用，比如排序，Validation、关系管理等。
一个Managed Object是不能独立于Context存在的，即有Managed Object就一定会有它的Context，也可以通过 Managed Object 的.managedObjectContext属性取得它的Context对象。
一旦设置了Managed Object的Context，那么在Object的很长的生命周期中就会一直跟这个特定的Context关联。
一个应用程序可以有很多个Context，你可以创建两个Context指向一些相同的PersistentStore持久化层。
Context并不是线程安全的，所以对于Managed Object也是一样的，它们只可以在创建他们的那个线程上进行操作。

08. 创建自己的线程栈

创建：CoreDataStack.swift

第一部分创建 Model 的名字和 Document 的路径URL：
创建新的 .swift 文件

import CoreData
class CoreDataStack {

  let modelName = "Dog Walk"

  //Document's URL
  private lazy var applciationDocumentDirectory: NSURL = {
    let urls = NSFileManager.defaultManager().URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask)
    return urls[urls.count-1]
  }()
}

第二步给类添加懒加载的三个属性 NSManagedObjectContext、NSPersistentStoreCoordinator和NSManagedObjectModel：

 //NSManagedObjectContext
 //Note: ConcurrencyType 的具体参数会在后面补充添加，暂时先使用 .MainQueueConcurrencyType
 //创建出来Context是完全没有意义的，直到设置了Context的PersistentStoreCoordinator
 lazy var context: NSManagedObjectContext = {
   var managedObjectContext = NSManagedObjectContext(concurrencyType: .MainQueueConcurrencyType)
   managedObjectContext.persistentStoreCoordinator = self.psc
   return managedObjectContext
 }()
 
 //NSPersistentStoreCoordinator
 //对StoreCoordinator做懒加载，StoreCoordinator是介与PersistentStore(s)和ObejctModel之间的，所以至少需要一个PersistentStore。
 private lazy var psc: NSPersistentStoreCoordinator = {
   //coordinator init，传入Model，Model指所有的Entity和所有的relationship
   let coordinator = NSPersistentStoreCoordinator(managedObjectModel: self.managedObjectModel)
//    PersisitentStore 的物理存储路径
   let url = self.applciationDocumentDirectory.URLByAppendingPathComponent(self.modelName)
   do{
//      一些Option配置：
     let options = [NSMigratePersistentStoresAutomaticallyOption : true]
//addPersistentStoreWithType 选择一个SQLite的type，使用SQLite作为存储模式。
     try coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL:url, options: options)
   } catch {
     print("Error adding persistnet store.")
   }
   return coordinator
 }()
 
 //NSManagedObjectModel
 //这里包含着MainBundle里面的momb文件里面的 `.xcdatamodeld` 文件，就是Xcode图形化设计Entity和Relationship的那个文件，使用它来创建ManagedObjectModel
 private lazy var managedObjectModel: NSManagedObjectModel = {
   let modelURL = NSBundle.mainBundle().URLForResource(self.modelName, withExtension: "momd")!
   return NSManagedObjectModel(contentsOfURL: modelURL)!
 }()

添加的每 Property 都对应着 Core Data 的重要组件，使用Lazy Loading，每个组件都依赖其他的组件。

这些 Property 中只有NSManagedObjectContext是 Public 的 Property，其余的都是 private 修饰。private 修饰的组件外界不需要获取的。

另外，NSPersistentStoreCoordinator可以通过 NSManagedObjectContext的 Public property 获取。

而所有的NSManagedObjectModel和NSPersistentStore都可以通过NSPersistentStoreCoordinator的Public property 来获取。

对StoreCoordinator做懒加载，它是介与PersistentStore(s)和ObejctModel之间的，所以至少需要一个PersistentStore。

最后添加一个方法：

//保存的方法
func saveContent () {
  if context.hasChanges {
    do {
      try context.save()
    } catch let error as NSError {
      print("Error: \(error.localizedDescription)")
      abort()
    }
  }
}

在AppDelegate中添加LazyLoading的iVar：

lazy var coreDataStack = CoreDataStack()

在didFinishLaunchingWIthOption的方法中可以给rootViewController中的Context赋值了：

let navigationController = window!.rootViewController as! UINavigationController
let viewController = navigationController.topViewController as! ViewController
viewController.managedContext = coreDataStack.context

接下来在合适的时机调用SaveContent方法，这里就是在applicationDidEnterBackground和applicationWillTerminate代理方法中调用：

coreDataStack.saveContent()

到这里，一个CoreData的栈类就创建完成了，并且已经实现了在应用退出的时候对 Context 进行 saveing 的操作

09.高级查询

简单的查询通过创建 NSFetchRequest 来从 CoreData 中取得数据。

下面展示四种查询数据的方式：

//1
let fetchRequest1 = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Person", inManagedObjectContext: managedObjectContext)! 
fetchRequest1.entity = entity

第一种方法通过默认初始化NSFetchRequest，从 managedContext 来创建 Person 类的 EntityDescription，然后设置fetchRequest的entity来完成。

//2
let fetchRequest2 = NSFetchRequest(entityName: "Person")

第二种方法可以在初始化NSFetchRequest的时候传入EntityName来完成，这是一种便捷的快速方法，在init的时候就制定了Entity。

//3
let fetchRequest3 = managedObjectModel.fetchRequestTemplateForName("peopleFR")

第三种通过调用managedObjectModel的.fetchRequestTemplateForName方法来获取 NSFetchRequest。在Xcode的 Data Model Editor 界面中可以手动设置一些针对用户需求常用的fetch属性，可以使用这种方法来快速调用。

//4
let fetchRequest4 = managedObjectModel.fetchRequestFromTemplateWithName("peopleFR", substitutionVariables: ["NAME" :"Ray"])

第四种基于第三种，但是会在第三种的基础上使用substitutionVariables进行再次的筛选。

在Editor上创建 Fetch Template

在 Data Model Editor 界面上长时间按住 Add Entity 的那个按钮，选择Add Fetch Request。

之后如果是查询一个实体的全部数据，就吧下拉框选为目标查询的实体。

几个小点：

从 Editor 模板中取得 FetchRequest 的时候必须从 ManagedObjectModel 中取。
构建的 CoreDataStack 类中只应该有 ManagedContext 是 Public 的，其余的都应该是 Private。
NSManagedObjectModel.fetchRequestTemplateForName()的参数必须跟 Editor 中的保持一致。

NSFetchRequest 神奇の存在

在 CoreData 框架中，NSFetchRequest 就像一把多功能的瑞士军刀，你可以批量获取数据，可以获取单个数据，可以获取最大最小、平均值等、

那么他是如何实现这些的呢，FR 有一个property叫做 resultType，默认值是 NSManagedResultType：

NSManagedObjectResultType:默认值，返回批量的 Managed Object 对象
NSCountResultType: 类型如其名，返回 ManagedObjects.count
NSDictionaryResultType: 返回不同的计算类型，稍后补充
NSManagedObjectIDResultType：返回特殊的标记，而不是真实的对象，其实这个有点儿像 hashCode 的意思

NSCountResultType 实现 count 计数

在获取了 FR 之后，需要给 FR 添加 predicate，predicate 在创建的时候支持 key path，比如：

lazy var cheapVenuePredicate: NSPredicate = {
  var predicate = NSPredicate(format: "priceInfo.priceCategory == %@", "$")
  return predicate
}()

上面代码中的 priceInfo.priceCategory 就是一个应用。

func populateCheapVenueCountLabel() {
  // $ fetch request
  let fetchRequest = NSFetchRequest(entityName: "Venue")
  fetchRequest.resultType = .CountResultType
  fetchRequest.predicate = cheapVenuePredicate
  do {
    let results = try coreDataStack.context.executeFetchRequest(fetchRequest) as! [NSNumber]
    let count = results.first!.integerValue
    firstPriceCategoryLabel.text = "\(count) bubble tea places"
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

这个方法使用上面的 LazyLoading 的iVar - cheapVenuePredicate 作为 predicate，来做数据查询。

这里指明了 fetchRequest.resultType = NSCountResultType，所以结果会返回一个包含了一个 NSNumber 的 NSArray。当然这个 NSNumber 是一个 NSInteger，它就是那个count。

除了上面的一种执行 executeFetchRequest 的方法获取Count的方法之外，还可以直接调用 context 的countForFetchRequest 方法来获取Count：

func populateExpensiveVenueCountLabel() {
  // $$$ fetch request
  let fetchRequest = NSFetchRequest(entityName: "Venue")
  fetchRequest.resultType = .CountResultType
  fetchRequest.predicate = expensiveVenuePredicate
  
  var error: NSError?
  let count = coreDataStack.context.countForFetchRequest(fetchRequest, error: &error)
  
  if count != NSNotFound {
    thirdPriceCategoryLabel.text = "\(count) bubble tea places"
  } else {
    print("Could not fetch \(error), \(error?.userInfo)")
  }
}

上面的代码中，使用的错误处理不是像之前使用的 try-catch 结构，而是使用 iOS SDK 中常见的 error 的结构，这是因为 countForFetchRequest 方法的第二个参数是一个 *NSError 类型，需要将一个 error 对象的指针传递进去。使用：

coreDataStack.context.countForFetchRequest(fetchRequest, error: &error)

来获取查询结果的 count。

DictionaryResultType 实现计算逻辑

前面说了，NSFetchRequest 可以左好多事情，这里包括了一些计算的逻辑。

对于某些需求，比如对查询的结构进行一些SUM、MIN、MAX这样的常见操作，常见一些低效率的代码把所有的数据全部查询出来，然后在程序中使用 For 循环来进行筛选，这样做又 Naive 又低效。

代码如下：

func populateDealsCountLabel() {
  //1 像之前一样普通的创建 NSFetchRequest，但是 resultType 指定为 .DictionaryResultType
  let fetchResult = NSFetchRequest(entityName: "Venue")
  fetchResult.resultType = .DictionaryResultType
  
  //2 创建一个 NSExpressionDescription 对象去请求 SUM，而且给它一个 name 标示“sumDeals”，在resultResults中就会有这个 name 标识的返回结果
  let sumExpressionDesc = NSExpressionDescription()
  sumExpressionDesc.name = "sumDeals"
  
  //3 上面仅仅给了 ExpressionDescription 一个name标示，但是只是一个String而已，真正让它清楚自己要做sum求和需要给ExpressionDesc对象的这个 .expression 对象做配置：
  //初始化一个 NSExpression 对象，function写上“sum”，还有好多，使用 command 键按进去方法描述下面一大堆，后面的 argument 参数指明对查询出来的结果的 specialCount 来进行逻辑计算。
  sumExpressionDesc.expression = NSExpression(forFunction: "sum:", arguments: [NSExpression(forKeyPath: "specialCount")])
  //指定计算结果的数据类型
  sumExpressionDesc.expressionResultType = .Integer32AttributeType
  
  //4 配置好了 NSExpressionDescription 对象之后，将配置好的它 set 为 NSFetchRequest 对象的 .propertiesToFetch（看见没这里是ties，意思要接受数组，而且可以配置好多个，配置多个就返回多个喽~）
  fetchResult.propertiesToFetch = [sumExpressionDesc]
  
  //5 司空见惯的查询，看从 resultDic 中取得查询结果的那个 [sumDeals] 就是前面 NSExpressDescription.name。
  do {
    let results = try coreDataStack.context.executeFetchRequest(fetchResult) as! [NSDictionary]
    let resultDic = results.first!
    let numDeals = resultDic["sumDeals"]
    numDealsLabel.text = "\(numDeals!) total deals"
  } catch let error as NSError {
    print("Could not fetch \(error), \(error.userInfo)")
  }
}

ManagedObjectIDResultType 查询结果的唯一标示

四种类型前面已经说了三种，接下来的一种就是 ManagedObjectIDResultType，这种查询类型会返回查询结果的一个特殊标志，一种 universal identifier 每一个 ManagedObject 对应着一个特殊的 ID。

之前笔者认为它像 hashCode 但是明显又不一样，因为即便是两个内容相同的 ManagedObjcet，他们的 ID 也都是不一样的，但是 HashCode 确应该是一样的。

iOS 5 的时候取得 NSManagedObjectID 是线程安全的，但是现在已被弃用，但是有更好的并发模型提供给我们使用，以后会有 CoreData 与多线程并发。

另外提两点：

NSFetchRequest 支持批量返回，可以通过设置 fetchBatchSize、fetchLimit 和 fetchOffset 去配置 Batch 的 FetchRequest。
另外可以通过 faulting 来优化内存消耗：fault 是一中占位符，它代表着一个还没有真正从存储层取出到内存的 ManagedObject。
另外一重优化内存的方法就是使用 predicate，接下来会写到。

（如果使用了 Editor 配置的 predicate，那么在 Runtime 的时候就不能更改 predicate。）

其实 NSPredicate 不属于 Core Data 框架，它是属于 Foundation 框架中的，更多有关于 NSPredicate 的，可以看苹果官方的文档。

FetchResults 排序

NSFetchRequest 另外一个神奇的功能是它能把获取的数据进行排序，实现的机制是使用 NSSortDescription 类，而且这个排序的执行时机是在 数据存储层 也就是在 SQLite 层完成的，保证了排序的速度和效率。

案例：需要排序的模块中加入 NSSortDescription 的 lazy Var 如下：

lazy var nameSortDescriptor: NSSortDescriptor = {
  var sd = NSSortDescriptor(key: "name", ascending: true, selector: "localizedStandardCompare:")
  return sd
}()

lazy var distanceSortDescription: NSSortDescriptor = {
  var sd = NSSortDescriptor(key: "location.distance", ascending: true)
  return sd
}()

第一个 NSSortDescription 按照姓名来进行排序，排序的比较方法选择了 String 的 localizedStandardCompare:。

第二个 NSSortDescription 按照 location.distance 进行排序。
ascending 参数表示是否要升序，true -> ascending，false -> descending。

注意：

在 Core Data 框架之外，NSSortDescriptor 支持基于 Block Closure 的 Comparator，这里我们用的是一个 selector。其实在 Core Data 框架内是不允许使用 Comparator 的方法来定义排序的。
同样的，供给 Core Data 使用的 NSPredicate 也是不允许使用任何基于 Block 的 API。
上面两点为什么呢？因为前面说了排序发生在数据存储层，也就是在SQLite查询的时候完成的，Block 的方式不能有效组成一个 SQLite 查询语句。

localizedStandardCompare 是什么，当你对用户看到的那些字符串进行排序的时候，Apple 都建议传递 localizedStandardCompare来当做排序的规则来对当前字符串进行排序。

如果要某个 SortDescriptor 的逆向排序，可以调用它的 .reversedSordDescriptor取得。

nameSortDescriptor.reversedSortDescriptor as? NSSortDescriptor

配置好了 SortDescription 之后，将 NSFetchRequest 的 sortDescriptors 属性设置为包含了 SortDescription 的数组：

fetchRequest.sortDescriptors = [sr]

异步Fetching（iOS 8 的特性）

如同很多其他 iOS 上的需求一样，当复杂且耗时长的工作放在主线程上，会造成线程阻塞，这个时候 UI 会处于一种假死的状态。同样的 Core Data 的 Fetch 也是一样的，在 Fetch 条件复杂、数据量很大的情况下，同样会造成线程阻塞。这个时候，这部分工作就应该异步执行。

Core Data 的异步执行被封装的相当简单，在已有的 FetchRequest 的基础上，使用 NSAsynchronousFetchRequest 来实现异步请求。

NSAsynchronousFetchRequest 的命名容易让人产生歧义，其实它并不是 FetchRequest 的 subclass，它跟 FetchRequest 一样，同样是 NSPersistentStoreRequest 的子类。也就是说实现异步的 Fetch 就是把 NSFetchRequest 替换为 NSAsynchronousFetchRequest。

首先在模块原有的 FetchRequest 中模块中添加 iVar 变量：

var asyncFetchRequest: NSAsynchronousFetchRequest!

NSAsynchronousFetchRequest 就像是已经存在的 FetchRequest 的一个 Wrapper 一样。创建一个 NSAsynchronousFetchRequest 需要一个正常的 FetchRequest 和一个 Completion Handle。

执行请求的时候类似，不过请求的方法从 executeFetchRequest 变成了 executeRequest，传递进去的参数也从 FetchRequest 变成了 AsynchronousFetchRequest。

执行请求之后，返回的数据为：NSAsynchronousFetchResult。

调用的方法如下：

fetchRequest = NSFetchRequest(entityName: "Venue")

asyncFetchRequest = NSAsynchronousFetchRequest(fetchRequest: fetchRequest) {
//查询成功的处理
  [unowned self] (result: NSAsynchronousFetchResult!) -> Void in
  self.venues = result.finalResult as! [Venue]
  self.tableView.reloadData()
}
do {
  try coreDataStack.context.executeRequest(asyncFetchRequest)
  //Returns immediately, cancel here if you want.
} catch let error as NSError {
  print("Could not fetch \(error), \(error.userInfo)")
}

block 之内是对返回的数据做处理。

另外，如果要取消正在，asyncFetchRequest 可以调用 cancel() 方法来取消这次异步请求。

批量更新（不做查询，直接在Store层进行更新，iOS 8 的特性)

举例一种情况，如果我们要对十万条数据都进行同样的一个属性的更新，一般的做法我们需要取出这十万条数据，我们取出十多万条数据只是为了做一个很简单的更新。

经典的案例是电子邮箱类似的APP中 标记所有邮件为已读 这样的需求，难道要把上千封邮件全部请求出来吗，显然不是。

iOS 8 发布了支持 批量更新(Bench Update) 的 NSBatchUpdateRequest，使用它可以在不做查询的情况下更新数据。

NSBatchUpdateRequest 实现的原理是完全绕开了 NSManagedObjectContext，直接去 NSPersistentStore 层去做 Update。

//这四行代码，在初始化的时候配置好EntityName, 配置影响的property和更改的值 以及 配置影响的Store，以及返回Result的数据类型。
//创建NSBatchUpdateRequest 的实例，entityName 作为初始化参数。
let batchUpdate = NSBatchUpdateRequest(entityName: "myEntityName")
//标明需要 Update 的 property 和 值
batchUpdate.propertiesToUpdate = ["favorite" : NSNumber(bool: true)]
//被影响的Stores 默认情况下这么写就可以，如果涉及比较多的PersistentStores 情况就更复杂了。
batchUpdate.affectedStores = coreDataStack.context.persistentStoreCoordinator!.persistentStores
//配置返回数据的类型，还可以是 UpdatedObjectIDsResultType。
batchUpdate.resultType = .UpdatedObjectsCountResultType

//执行批量更新
do {
  let batchResult = try coreDataStack.context.executeRequest(batchUpdate) as! NSBatchUpdateResult
  print("Records updated \(batchResult.result!)")
} catch let error as NSError {
    print("Could not update \(error), \(error.userInfo)")
}

在初始化的时候配置好EntityName, 配置影响的property和更改的值以及配置影响的Store，以及返回Result的数据类型。

另外提一下：如同这种在 Store 层的数据更新，数据删除也有同样的API，在 iOS 9 的时候苹果提供了一个类似 NSBatchUpdateRequest 的类来做在 Store 层的数据删除，使用 ---- NSBatchDeleteRequest，同样它们两个都是 NSPersistentStoreRequest 的子类。

注意：

额外需要注意的一点是，前面提到了「NSBatchUpdateRequest 实现的原理是完全绕开了 NSManagedObjectContext，直接去 NSPersistentStore 层去做 Update。」

所以做了批量 Update / Delete 之后，你之前请求的那部分数据已经失效了，因为它们跟数据库已经失去了同步性。

End.