«Introduction to Core Data Programming Guide 11 Who Should Read This Document 11 Organization of This Document 11 See Also 13 Technology Overview 14 ...»
“Creating and Deleting Managed Objects” (page 56) describes how to correctly instantiate and delete ● managed objects programmatically.
2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.
Introduction to Core Data Programming Guide Organization of This Document “Fetching Managed Objects” (page 61) describes how to fetch managed objects, and some considerations ● to ensure that fetches are efficient.
“Using Managed Objects” (page 67) describes issues related to manipulating managed objects in your ● application.
“Object Lifetime Management” (page 79) describes aspects of memory management when using Core ● Data.
“Relationships and Fetched Properties” (page 82) describes relationships, how to model them, and issues ● related to manipulating relationships between managed objects. It also describes fetched properties, which are like weak unidirectional relationships.
“Non-Standard Persistent Attributes” (page 91) describes how to use attributes with non-standard value ● types (such as colors and C-structures).
“Managed Object Validation” (page 103) describes types of validation, how to implement validation methods, ● and when to use validation.
“Faulting and Uniquing” (page 110) describes how Core Data constrains the size of the object graph, and ● ensures that each managed object within a managed object context is unique.
“Using Persistent Stores” (page 115) describes how you create a persistent store, how you can migrate a ● store from one type to another, and manage store metadata.
“Core Data and Cocoa Bindings” (page 120) describes how Core Data integrates with and leverages Cocoa ● bindings.
“Change Management” (page 124) describes the issues that may arise if you create multiple managed ● object contexts or multiple persistence stacks.
“Persistent Store Features” (page 130) describes the features of the different types of store, and how you ● can configure the behavior of the SQLite store.
“Concurrency with Core Data” (page 136) describes how to use concurrent programming in a Core Data ● application.
“Core Data Performance” (page 140) describes techniques you can use to ensure a Core Data application ● is as efficient as possible.
“Troubleshooting Core Data” (page 149) describes common errors developers make when using Core Data, ● and how to correct them.
“Efficiently Importing Data” (page 160) describes how you can import data into a Core Data application.
● “Core Data FAQ” (page 165) provides answers to questions frequently asked about Core Data.
● “Glossary” (page 176) provides a glossary of terms used in Core Data.
You should also refer to:
Core Data Starting Point ● Core Data Tutorial for iOS ● Core Data Utility Tutorial ● Core Data Model Editor Help ●
This article describes the basic features provided by Core Data, and reasons why it might be appropriate for you to adopt the technology.
Core Data Features The Core Data framework provides generalized and automated solutions to common tasks associated with
object life-cycle and object graph management, including persistence. Its features include:
Change tracking and undo support.
● Core Data provides built-in management of undo and redo beyond basic text editing.
● Core Data manages change propagation, including maintaining the consistency of relationships among objects.
● Core Data can reduce the memory overhead of your program by lazily loading objects. It also supports partially materialized futures, and copy-on-write data sharing.
Automatic validation of property values.
● Core Data’s managed objects extend the standard key-value coding validation methods that ensure that individual values lie within acceptable ranges so that combinations of values make sense.
● Dealing with a change to your application’s schema can be difficult, in terms of both development effort and runtime resources. Core Data’s schema migration tools simplify the task of coping with schema changes, and in some cases allow you to perform extremely efficient in-place schema migration.
Optional integration with the application’s controller layer to support user interface synchronization.
● Core Data provides the NSFetchedResultsController object on iOS, and integrates with Cocoa Bindings on OS X.
Full, automatic, support for key-value coding and key-value observing.
● In addition to synthesizing key-value coding and key-value observing compliant accessor methods for attributes, Core Data synthesizes the appropriate collection accessors for to-many relationships.
Grouping, filtering, and organizing data in memory and in the user interface.
● Automatic support for storing objects in external data repositories.
● Sophisticated query compilation.
● Instead of writing SQL, you can create complex queries by associating an NSPredicate object with a fetch request. NSPredicate provides support for basic functions, correlated subqueries, and other advanced SQL. With Core Data, it also supports proper Unicode, locale-aware searching, sorting, and regular expressions.
● Core Data provides built in version tracking and optimistic locking to support automatic multi-writer conflict resolution.
Why Should You Use Core Data?
There are a number of reasons why it may be appropriate for you to use Core Data. One of the simplest metrics is that, with Core Data, the amount of code you write to support the model layer of your application is typically 50% to 70% smaller as measured by lines of code. This is primarily due to the features listed above—the features Core Data provides are features you don’t have to implement yourself. Moreover they’re features you don’t have to test yourself, and in particular you don’t have to optimize yourself.
Core Data has a mature code base whose quality is maintained through unit tests, and is used daily by millions of customers in a wide variety of applications. The framework has been highly optimized over several releases.
It takes advantage of information provided in the model and runtime features not typically employed in application-level code. Moreover, in addition to providing excellent security and error-handling, it offers best memory scalability of any competing solution. Put another way: you could spend a long time carefully crafting your own solution optimized for a particular problem domain, and not gain any performance advantage over what Core Data offers for free for any application.
In addition to the benefits of the framework itself, Core Data integrates well with the OS X tool chain. The model design tools allow you to create your schema graphically, quickly and easily. You can use templates in the Instruments application to measure Core Data’s performance, and to debug various problems. On OS X desktop, Core Data also integrates with Interface Builder to allow you to create user interfaces from your model.
These aspects help to further shorten your application design, implementation, and debugging cycles.
What Core Data Is Not Having given an overview of what Core Data is and does, and why it may be useful, it is also useful to correct some common misperceptions and state what it is not.
Core Data is not a relational database or a relational database management system (RDBMS).
● Core Data provides an infrastructure for change management and for saving objects to and retrieving them from storage. It can use SQLite as one of its persistent store types. It is not, though, in and of itself a database. (To emphasize this point: you could for example use just an in-memory store in your application.
You could use Core Data for change tracking and management, but never actually save any data in a file.) Core Data is not a silver bullet.
● Core Data does not remove the need to write code. Although it is possible to create a sophisticated application solely using the Xcode data modeling tool and Interface Builder, for more real-world applications you will still have to write code.
Core Data does not rely on Cocoa bindings.
● Core Data integrates well with Cocoa bindings and leverages the same technologies—and used together they can significantly reduce the amount of code you have to write—but it is possible to use Core Data without bindings. You can readily create a Core Data application without a user interface (see Core Data Utility Tutorial ).
This article describes the basic Core Data architecture, and the way you use the framework.
Basic Core Data Architecture In most applications, you need a means to open a file containing an archive of objects, and a reference to at least one root object. You also need to be able to archive all the objects to a file and—if you want to support undo—to track changes to the objects. For example, in an employee management application, you need a means to open a file containing an archive of employee and department objects, and a reference to at least one root object—for example, the array of all employees—as illustrated in Figure 1 (page 18). You also need to be able to archive to a file all the employees and all the departments.
2012-09-19 | Copyright © 2004, 2012 Apple Inc. All Rights Reserved.
Core Data Basics Basic Core Data Architecture Note : This document uses the employees example for reasons of expediency and clarity. It represents a rich but easily understood problem domain. The utility of the Core Data framework, however, is not restricted to database-style applications, nor is there an expectation of client-server behavior.
The framework is equally useful as the basis of a vector graphics application such as Sketch or a presentation application such as Keynote.
You are responsible for writing the code that manages these tasks either in whole or in part. For example, on OS X desktop, the Cocoa document architecture provides an application structure and functionality that helps to reduce the burden, but you still have to write methods to support archiving and unarchiving of data, to keep track of the model objects, and to interact with an undo manager to support undo.
Figure 1 Document management using the standard Cocoa document architecture
Using the Core Data framework, most of this functionality is provided for you automatically, primarily through an object known as a managed object context (or just “context”). The managed object context serves as your gateway to an underlying collection of framework objects—collectively known as the persistence stack—that mediate between the objects in your application and external data stores. At the bottom of the stack are persistent object stores, as illustrated in Figure 2 (page 19).
Figure 2 Document management using Core Data Core Data is not restricted to document-based applications—indeed it is possible to create a Core Data–based utility with no user interface at all (see Core Data Utility Tutorial ). The same principles apply in other applications.
Managed Objects and Contexts You can think of a managed object context as an intelligent scratch pad. When you fetch objects from a persistent store, you bring temporary copies onto the scratch pad where they form an object graph (or a collection of object graphs). You can then modify those objects however you like. Unless you actually save those changes, however, the persistent store remains unaltered.
Model objects that tie into in the Core Data framework are known as managed objects. All managed objects must be registered with a managed object context. You add objects to the graph and remove objects from the graph using the context. The context tracks the changes you make, both to individual objects' attributes and to the relationships between objects. By tracking changes, the context is able to provide undo and redo support for you. It also ensures that if you change relationships between objects, the integrity of the object graph is maintained.