iOS10 CoreData新特性

原文地址：What's New in Core Data in macOS 10.12, iOS 10.0, tvOS 10.0, and watchOS 3.0

翻译者：肖品，原创文章转载请著名出处。

Core Data在 macOS 10.12 , iOS 10.0, tvOS 10.0和watchOS 3.0中的新特性

This document describes the new areas of functionality in Core Data in macOS 10.12, iOS 10.0, tvOS 10.0, and watchOS 3.0. Please note that many Swift APIs are renamed in accordance with Swift 3 API design guidelines. Please refer to Swift Evolution document SE-0023, "API Design Guidelines."

这个文档描述了CoreData在 macOS 10.12, iOS 10.0，tvOS 10.0 和 watchOS 3.0的新功能。请注意有许多Swift的API 根据Swift 3 API 设计指南进行了重命名。请参考 Swift 进化文档 SE-0023, ”API 设计指南“

Concurrency changes and connection pooling

并发变化和连接池

The NSPersistentStoreCoordinator now maintains a small connection pool that allows concurrent database operations for NSSQLiteStoreType persistent stores. An NSManagedObjectContext (that is not nested) can now fetch and fault concurrently with other peer NSManagedObjectContext instances. For persistent stores using WAL journal_mode (the default in Core Data), the NSPersistentStoreCoordinator also supports 1 writer concurrently with multiple readers. For example, a UI context can fetch data concurrently with a single background context importing changes. Connection pooling uses less memory and generally out performs multiple separate NSPersistentStoreCoordinator instances to the same file.

NSPersistentStoreCoordinator(持久化协调者) 现在维持了一个小连接池，来NSSQLiteSToreType持久化进行并发数据操作。一个NSManagedObjectContext（对象上下文）和它对等的NSManagedObjectContext实例可以马上取数据和让并发失效。CoreData持久化默认使用的是WAL journal_mode, NSPersistentStoreCoordinator也支持1个写入者和多个读取者并发。举个例子：一个后台上下文在载入改变 ，同时一个界面上下文在读取数据。 对于同一个文件，连接池会使用较少的内存，多个NSPersistentStoreCoordinator实例对象通常都会分开执行。

This behavior is enabled for all existing Core Data clients. The default number of connections varies by platform but is greater than 1. You can adjust the behavior with the NSPersistentStoreConnectionPoolMaxSizeKey in your options dictionary when adding the store to the coordinator. NSPersistentStoreCoordinator briefly dispatches requests through its own queue, and custom code in blocks passed to NSPersistentStoreCoordinator.perform or NSPersistentStoreCoordinator.performAndWait will block the NSPersistentStoreCoordinator from routing future requests until they complete. Nested NSManagedObjectContext instances still serialize requests against their parent context as before.

在已经存在CoreData的客户端 这种行为是允许的。默认连接数量根据平台而异，但都是大于1。你在添加存储协调者的时候可以配置NSPersistentStoreConnectionPoolMaxSizeKey来调整行为。NSPersistentStoreCoordinator通过它的队列可以对所有请求短暂的分派，也可以通过NSPersistentStoreCoordinator.perform或者NSPersistentStoreCoordinator.performAndWait编写自定义代码，完成以后回调到指定的方法或Block代码块。嵌套的NSManagedObjectContext实例依旧针对父上下文保持连续请求。

 

NSPersistentContainer

持久容器

NSPersistentContainer is a new class that simplifies creating a new Core Data stack. It maintains references to your NSManagedObjectModel, NSPersistentStoreCoordinator, and other resources. NSPersistentContainer uses a new class NSPersistentStoreDescription to describe the configuration information to pass to NSPersistentStoreCoordinator when adding a persistent store. NSPersistentStoreDescription defaults to an NSSQLiteStoreType with automatic light weight migration enabled. The Xcode new project assistant for creating new iOS projects (but not macOS) that use Core Data now uses NSPersistentContainer in the AppDelegate. An example:

NSPersistentContainer是一个新类，它简化了创建一个心的CoreData堆。它维持了你项目中的NSManagedObjectModel ，NSPersistentStoreCoordinator 和其他资源的引用。在添加一个持久化存储的时候，NSPersistentContainer使用了一个新类NSPersistentStoreDescription来描述配置信息，并传到NSPersistentStoreCoordinator。NSPersistentStoreCoordinator默认可以自动对一个NSSQLiteStoreType进行迁移。在Xcode中新建iOS项目中，使用CoreData现在在AppDelegate中使用

NSPersistentContainer，示例如下：

let container = NSPersistentContainer(name: "myAppName")
container.loadPersistentStores(completionHandler: { (storeDescription, error) in
    if let error = error {
        fatalError("Unresolved error (error), (error.userInfo)")
    }
    container.viewContext.perform({
        // actions upon the NSMainQueueConcurrencyType NSManagedObjectContext for this container
    })
})

　　

This will find a model resource in the main bundle named after "myAppName", load it, create a new NSPersistentStoreCoordinator, and add a persistent store with the same name in the defaultDirectoryURL. The configuration details can be changed on the NSPersistentContainer before calling loadPersistentStores.

这个代码会在MainBundle资源库中找到一个名为”myAppName“的模型资源，加载它，创建一个新的NSPersistentStoreCoordinator持久化协调者，并在defaultDirectoryURL 这个默认路径下创建一个同名的持久化仓库。在还没有执行loadPersistentStores方法前，NSPersistentContainer持久化容器的配置是可以改变的。

 

NSPersistentContainer also has a few amenities for working with NSManagedObjectContext instances, including a single main queue context suitable for use with the view layer and factory methods for background contexts. You can also just give a block to the NSPersistentContainer which will asynchronously complete the task.

NSPersistentContainer持久化容器也给NSManagedObjectContext提供了一些便利的东西，包括在主线程队列中配合视图层和后台的方法使用，也可以在给一个Block异步调用。

let container = NSPersistentContainer.persistentContainerWithName("myApp")
container.performBackgroundTask() { (moc) in
    // use moc to do asynchronous work
}

　　

Query generations for transient versioning

瞬态多版本中的查询生成者

Core Data now supports pinning an NSManagedObjectContext to a specific query generation (database transaction) for arbitrarily many operations. A new class NSQueryGenerationToken represents an object that can be used to specify a pinning behavior or a specific version from another context. You can ask a context for its current queryGenerationToken or set one with setQueryGenerationFromToken(:) A nil token represents unpinned, which is the default behavior. Unpinned is the same NSManagedObjectContext behavior as previous releases. currentQueryGenerationToken is a token that can be passed to a context to tell it to lazily retrieve the most recent version on its next read operation (fetching or faulting) and then pin itself to that point in time. Calling save(), reset(), mergeChangesFromContextDidSaveNotification:, or mergeChangesFromRemoteContextSave(:intoContexts:) on any pinned context will automatically advance it to the most recent version for the operation and then reset its query generation to currentQueryGenerationToken.

The persistent store must be an NSSQLiteStoreType in WAL journal_mode (the default). Query generations expire if no contexts refer to them or the process terminates.

As an example:

对于许多反复无常的操作，CoreData现在支持针对一个特殊的查询生成对象（数据库事务）阻塞一个 NSManagedObjectContext ，一个新类NSQueryGenerationToken表示一个对象能在一个特殊的阻塞行为或者一个其他上下稳重特殊版本中被使用。你可以给当前queryGenerationToken或者调用setQueryGenerationFromToken(:) 设置一个token来请求一个上下文。默认nil表示没有绑定的。去除绑定和先前NSManagedObjectContext行为释放一样。currentQueryGenerationToke是一个可以通过一个上下文的令牌，并在告诉它在最近的一个版本在读取操作（读取或断开）的时候延迟得到最近的版本对象，然后及时的自己绑定。在任何已经绑定的上下文中请求save(), reset(), mergeChangesFromContextDidSaveNotification:, 或者 mergeChangesFromRemoteContextSave(:intoContexts:) 将会自动推荐最近版本的操作，然后重置currentQueryGenerationToken.

这个持久化仓库必须是一个基于 WAL journal_mode 的一个 NSSQLiteStoreType. 如果这些查询生成者不属于任何一个上下文或者他们在过程中终止，他们就会失效终止。

例如：

try container.viewContext.setQueryGenerationFromToken(NSQueryGenerationToken.currentQueryGenerationToken)
let request = NSFetchRequest(entityName:"Animal")
request.fetchBatchSize = 10
let results = try container.viewContext.executeFetchRequest(request)
let first = results.first
var aname = first.name // pull in the first batch's row data
 
let moc = container.newBackgroundContext
 
moc.performBlockAndWait() {
    let update = NSBatchUpdateRequest(entityName:"Animal")
    update.resultsType = .UpdatedObjectsCountResultType
    update.propertiesToUpdate = ["name" : NSExpression(forConstantValue:"Cat")]
    do {
        let result = try moc.executeRequest(update)
    } catch {
        print("Error executing update: (error)")
    }
}
 
var next = results[100]
aname = next.name // new reads from the batched fetch result still pull the previous verison's data
 
try container.viewContainer.setQueryGenerationFromToken(NSQueryGenerationToken.currentQueryGenerationToken)
 
next = results[200]
aname = next.name //now new reads from the batching result pull in the new Cat data

　

Managed Objects and subclassing

托管的对象和子类

If there is a 1:1 mapping between NSEntityDescription instances and custom NSManagedObject subclasses defined in your data model, Core Data will provide strongly typed conveniences on NSManagedObject subclasses in lieu of the string based NSEntityDescription class methods. These include the following new methods on NSManagedObject:

 如果在你数据模型中，在NSEntityDescription 实例和自定义的NSManagedObject子类之间有一对一的对应映射关系，Core Data将在NSManagedObject子类中提供强类型的便利 来替代基于字符串的 NSEntityDescription类方法。在NSManagedObject中包含如下方法：

public class func entity() -> NSEntityDescription
public class func fetchRequest() -> NSFetchRequest<NSFetchRequestResult>
public convenience init(context moc: NSManagedObjectContext)

　　

The binding between entities and subclasses happens when the NSManagedObjectModel is first used to initialize an NSPersistentStoreCoordinator. If the mapping between NSEntityDescription instances and subclasses is ambiguous, the functionality is disabled. You should avoid creating new copies of the same NSManagedObjectModel by reloading it from disk repeatedly.

当NSManagedObjectModel（托管数据模型） 第一次使用NSPersistentStoreCoordinator （持久化协调者）的时候，就会将所有实体和所有子类进行绑定。如果NSEntityDescription实例和子类之间映射有歧义的话，函数是不可用的。你应该避免相同的NSManagedObjectModel在加载的时候反复从磁盘中创建新的复制版本。

 

Fetch Requests

读取请求

NSFetchRequest is now a parameterized type based on a new NSFetchRequestResult protocol. Several Core Data APIs now refer to the parameterized NSFetchRequest in both Objective-C and Swift.

NSFetchRequest是基于一个新的NSRetchRequestResult 协议的参数化类型。 几个CoreData API方法，参考OC和Swift 参数化类型的NSFetchRequest

Additionally in Swift, NSManagedObjectContext offers parameterized variants of fetch(:), the Swift 3 name for executeFetchRequest:error:, and count(:).

此外在Swift中，NSManagedObjectContext存在参数化变体 fetch(:) 和 count(:) ,  executeFetchRequest:error:在Swift 3中的命名

public func fetch<T : NSFetchRequestResult>(_ request: NSFetchRequest<T>) throws -> [T]
public func count<T : NSFetchRequestResult>(for request: NSFetchRequest<T>) throws -> Int

　　

Bringing these changes together, in Swift 2 you might have had something like:

一起带来这些改变，在Swift 2 中可能有像这样的一些东西：

func findAnimals() {
    let request = NSFetchRequest(entityName:”Animal")
        do {
        guard let searchResults = try context.executeFetchRequest(request) as? [Animal] else {
        print("Results were not of the expected structure")
        }
        ... use(searchResults) ...
        } catch {
        print("Error ocurred during execution: (error)")
    }
}

　　

and in Swift 3:

在Swift 3中：

func findAnimals() {
    let request: NSFetchRequest<Animal> = Animal.fetchRequest
    do {
        let searchResults = try context.fetch(request)
        ... use(searchResults) ...
    } catch {
        print("Error with request: (error)")
    }
}

　　

NSFetchRequest also offers a new method execute() which can only be called within the scope of an NSManagedObjectContext instance's perform or performAndWait block's lexical scope. execute() directs that NSManagedObjectContext to execute the fetch request like:

NSFetchRequest 提供了一个新的方法 execute() , 但是它只能在NSManagedObjectContext 实例的 perform 或者 performAndWait 的Block(闭包)作用域中使用，使用示例如下：

func findAnimals() {
    context.performAndWait({
        let request : NSFetchRequest<Animal> = Animal.fetchRequest
        do {
            let searchResults = try request.execute()
            ... use(searchResults) ...
        } catch {
            print("Error with request: (error)")
        }
    })
}

　　

NSFetchedResultsController

查询结果控制器

The NSFetchedResultsController is now available on macOS 10.12. As with NSFetchRequest, it has become a parameterized type which it carries through to collections and methods derived from the NSFetchRequest that defines it.

NSFetchedResultsController目前只在 macOS 10.12 上可用。(未完待续。。。)

 

Xcode automatic subclass generation

Xcode now supports automatic generation of NSManagedObject subclasses in the modeling tool. In the entity inspector:

• Manual/None is the default, and previous behavior; in this case you should implement your own subclass or use NSManagedObject.
• Category/Extension generates a class extension in a file named like ClassName+CoreDataGeneratedProperties. You need to declare/implement the main class (if in Obj-C, via a header the extension can import named ClassName.h).
• Class Definition generates subclass files named like ClassName+CoreDataClass as well as the files generated for Category/Extension.

The generated files are placed in DerivedData and rebuilt on the first build after the model is saved. They are also indexed by Xcode, so command-clicking on references and fast-opening by filename works.

Core Data iCloud Deprecation

As of macOS v10.12 and iOS 10.0; Core Data's iCloud integration feature has been deprecated. Apps will continue to work. There are no changes to or removal of the functionality in macOS 10.12 and iOS 10. Historically, deprecated symbols in Cocoa remain functional for a considerable period of time before removal. Only the client side Core Data iCloud API symbols are deprecated. Core Data with iCloud is built on top of the iCloud Drive service. The service pieces are not effected in any way. If and when the deprecated APIs are disabled in some future OS version, applications running on iOS 9 or 10 will continue to work.

Miscellaneous new API

• NSManagedObjectContext now provides a property automaticallyMergesChangesFromParent that causes it to automatically register as an observer of NSManagedObjectContextDidSaveNotification posted by its parent store and call one of the mergeChanges methods upon itself.
• NSPersistentStoreCoordinator provides a new addPersistentStoreWithDescription(:completionHandler:) method that takes an NSPersistentStoreDescription and uses it to call, optionally asynchronously, addPersistentStoreWithType:configuration:URL:options:error:.

Behavioral changes

Core Data has changed two behaviors for applications built with a minimum deployment target of macOS 10.12, iOS 10.0, tvOS 10.0, or watchOS 3.0.

• performBlockAndWait: implicitly includes an autorelease pool around each block. Projects using ARC or Swift should be generally unaffected, although remember that both NSError** out parameters and exceptions are autoreleased and do not escape block lexical scope happily. Projects using manual retain / release will need to retain autoreleased objects, including the results of executeFetchRequest:error: inside the block and release or autorelease them outside the block's lexical scope. For example:

__block id result = nil;
[context performBlockAndWait:^{
    NSError* error = nil;
    result = [context executeFetchRequest:request error:&error];
}];
return result;

　　

This code works under ARC but under manual retain release must instead be:

__block id result = nil;
[context performBlockAndWait:^{
    NSError* error = nil;
    result = [[context executeFetchRequest:request error:&error] retain];
}];
return [result autorelease];

　　

• NSManagedObjectContext now defaults to a nil NSUndoManager on macOS. It always defaulted to nil on iOS.
• NSFetchedResultsController now correctly merges changes from other context for objects it hasn’t seen in its own context
• NSFetchRequest now allows predicates to specify an entity restriction allowing fetches against entity hierarchies in which only some sub entities have the relevant property such as:

• @“self.entity = %@ and subentityProperty = %@“ or even @“relationship.entity = %@ and relationship.onlysomedestinationsubentitiesAttribute = %@“
  
  Only one restricting entity qualifier per clause is allowed.
  

• Core Data has adopted the new logging infrastructure in 10.12 and iOS 10.0, and switched from using NSLog to os_log with the logging subsystem "com.apple.coredata". The output of this logging can be viewed in the Console application, or in terminal with the command:

• log stream —predicate 'subsystem = "com.apple.coredata"'
  
  As part of this transition, Core Data honors user defaults to log to os_log, stderr, or both with ‘com.apple.CoreData.Logging.oslog’ or ‘com.apple.CoreData.Logging.stderr’. Due to a known issue in Xcode, it may be useful to toggle stderr logging on during debugging.
  

  　　

• NSManagedObject dynamic accessor generation has fixed issues to properly generate accessors for ordered to-many relationships. Core Data will generate any of the “Mutable Indexed Accessors” documented in Key-Value Coding Accessor Methods. Both ordered and unordered to-many relationships support all of the “Mutable Unordered Accessors” except intersection<Key>.The potentially generated accessors include a getter named exactly as the property name from the data model, or the following list where * is the capitalized property name:
• set*:
• primitive*
• setPrimitive*:
• add*Object:
• add*:
• remove*Object:
• remove*:
• removeObjectFrom*AtIndex:
• remove*AtIndexes:
• remove*:
• insertObject: in*AtIndex:
• insert*: AtIndexes:
• replaceObjectIn*AtIndex: withObject:
• replace*AtIndexes: with*:
• validate*: error:
• willChange*
• didChange*
• willAccess*
• didAccess*
• NSManagedObject will now also allow subclasses to override accessors and still invoke the implementation that otherwise would have been dynamically generated. This can be done by invoking a method named identically to the overridden method with ‘managedObjectOriginal_’ prepended. For example:

　

- (void)setDepartment:(Department *)value
{
    // invoke the dynamic implementation of setDepartment
    [self managedObjectOriginal_setDepartment:value];
 
    NSLog(@"invoked %@", NSStringFromSelector(_cmd));
}