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));
}