Использование в своих интересах новых функций: соединение

Базовые Данные обеспечивают много главных новых функций и улучшений в OS X v10.5. Можно использовать в своих интересах их в OS X v10.5 при тихом поддержании назад совместимости с OS X v10.4 при условии, что Вы соединяете свое приложение соответственно.

Существует два способа, которыми можно разработать (в OS X v10.5) проект, работающий и на OS X v10.4 и на OS X v10.5:

1. Разработайте проект Тигра против OS X v10.4 SDK.

2. Разработайте проект Leopard против OS X v10.5 SDK и установите “Развертывание OS X Target” в OS X v10.4.

Право преимущественной покупки - то, что большинство разработчиков делает по умолчанию. Это означает, однако, что даже в OS X v10.5 выполнение приложения как OS X v10.4 приложение и не может использовать новые функции или монопольные исправления ошибок. Для использования в своих интересах новых функций и исправлений ошибок необходимо разработать проект против OS X v10.5 SDK и установить “Развертывание OS X Target” в OS X v10.4.

Управление версиями хранилища и миграция

Одна из главных новых функций Leopard является архитектурой для поддержки управления версиями, и миграция — см. Базовое Руководство по программированию Управления версиями и Миграции данных Модели данных для большего количества подробных данных.

Персистентное хранилище API

Одна из главных новых функций Leopard является способом, которым можно создать собственный персистентный тип хранилища. Вы используете новое NSPersistentStore и NSAtomicStore классы — дополнительную информацию см. в Атомарных Темах Программирования Хранилища. Персистентные хранилища в целом обсуждены в Персистентных Функциях Хранилища и Используя Персистентные Хранилища.

64-разрядный

В OS X v10.5, Базовые Данные полностью 64-разрядные совместимый.

NSManagedObject

В OS X v10.5, NSManagedObject кластер класса. На практике это не должно обычно иметь никакого значения к коду, который Вы пишете. Это действительно означает, однако, что необходимо использовать надлежащие образцы Какао при переопределении инициализатора — т.е. необходимо гарантировать, что Вы устанавливаете self к возвращаемому значению от вызова реализации super, как показано в следующем примере:

- (id)initWithEntity:(NSEntityDescription*)entityinsertIntoManagedObjectContext:(NSManagedObjectContext*)context {

    self = [super initWithEntity:entity insertIntoManagedObjectContext:context];

    if (self) {

        // Perform additional initialization.

    }

    return self;

}

primitiveValueForKey: больше поддержки несмоделированные свойства — нет никакой поддержки неопределенных ключей.

NSManagedObject использует динамическую генерацию класса для поддержки Objective C 2 функции свойств (см. Objective C 2 Поддержки) путем автоматического создания подкласса класса, подходящего для объекта. Это также обычно очевидно для Вас, однако тогда как NSManagedObject class метод возвращает Ваш класс, функцию Objective C object_getClass возвращает динамично сгенерированный класс.

Как кластер класса, NSManagedObject alloc/initWithEntity:insertIntoManagedObjectContext: пара будет всегда возвращать экземпляр корректного класса для объекта, который Вы передаете как параметр. Динамично сгенерированный подкласс будет основываться на классе, указанном объектом, так указывая, что пользовательский класс в Вашей модели заменит класс, переданный alloc.

@interface Parent : NSManagedObject

@property(retain) NSString* foo;

@end

@implementation Parent

@dynamic foo;

@end

@interface Child : Parent

@end

@implementation Child

- (NSString*) foo {

    // This throws a "selector not found" exception.

    return super.foo;

}

@end

Выборка

При создании запроса выборки можно использовать setRelationshipKeyPathsForPrefetching: указать ключ соединяет каналом для отношений, которые должны быть выбраны с целевым объектом. Существуют многочисленные другие новые параметры конфигурации для запросов выборки — посмотрите NSFetchRequest для полного изложения.

Производительность и многопоточность

Новый API для NSFetchRequest может быть чрезвычайно полезным в работе с данными между потоками. Например, можно сконфигурировать запрос выборки к эхо-сигналу IDs, но исключить данные строки (и обновить кэш строки) — это может быть полезно, если Вы просто собираетесь передать те идентификаторы объектов от фонового потока до другого потока. Можно также выбрать отношения с упреждением (который избегает проблемы, описанной в «Упреждающей выборке» в Базовой Производительности Данных), и предварительно заполните управляемые объекты (т.е. отключите ленивую инициализацию — который избегает проблемы, описанной в “Пакете, дающем сбой” в Базовой Производительности Данных).

В OS X v10.5, executeFetchRequest:error: внутренне масштабирует его поведение соответственно для аппаратных средств и рабочей нагрузки. Если необходимо, Базовые Данные создадут дополнительные частные потоки для оптимизации выбирающей производительности. Вы теперь не улучшите абсолютную выбирающую скорость путем создания фоновых потоков (несмотря на то, что может все еще быть надлежащим выбрать в фоновом потоке для улучшенной скорости отклика — т.е. препятствовать тому, чтобы приложение блокировало).

Базовые Данные теперь пытаются оптимизировать штабель, разъединяют (уничтожение персистентного координатора хранилища, персистентных хранилищ, и т.д.). Когда штабель разъединяется, dealloc метод объектов компонента нельзя вызвать. Вы не должны поэтому делать очистки ресурса (такой как удаление временных файлов) в a dealloc метод, вместо этого необходимо лишить законной силы ресурсы, когда они больше не необходимы.

Изменения были внесены в политики слияния улучшить устойчивость и избежать возрождать определенные объекты. В OS X v10.4, были проблемы с объектами, имеющими с отношениями к удаленным объектам, когда удалить правила расположились бы каскадом, имел все изменения, сделанный в том же контексте. В OS X v10.5, дескриптор политик слияния удаляет каскады распространения правильно даже между процессами с разрозненными обновлениями.

Анализ эффективности

Базовые Данные теперь предоставляют поддержку для различного dtrace зонды, которые могут также использоваться с Инструментами — видят “Производительность Анализа” в Базовой Производительности Данных для получения дополнительной информации.

Удаление объектов

В OS X v10.4, Вы не могли вызвать deleteObject: в методе доступа набора; в OS X v10.5 Вы может.

В OS X v10.4, Вы не могли удалить объект, если бы это был отказ, который не мог бы быть выполнен (т.е. уже удаленный другим контекстом или процессом). В OS X v10.5, можно всегда удалять отказы к без вести пропавшим записей.

В OS X v10.5, Базовые Данные не позволят Вам сохранить граф объектов, если на этапе проверки это будет содержать ссылку на удаленный объект. Например, если удаленный объект будет иметь отношение к другому объекту, во время операции Core Data сохранения генерирует отклонять ошибку. Это может произойти особенно, если Вы не указали отношение без инверсии, или если после распространения удалений Вы добавляете ссылку на удаленный объект. Это - изменение в поведении от OS X v10.4 ( OS X v10.4 не генерировал бы, отклоняют ошибки). При ручном выполнении проверки Вы, возможно, должны вызвать processPendingChanges сначала так, чтобы удаления и другие объединенные операции располагаются каскадом полностью для чистки любых ссылок на незаконченные удаления от графика.

Опции хранилища SQLite

В OS X v10.4, существует только две настройки для управления путем, которым данные в находящемся в SQLite хранилище записаны в диск. Для обеспечения более прекрасной гранулярности управления компромиссом между производительностью, и надежность, в OS X v10.5 Базовые Данные использует две независимых прагмы для управления этими опциями.

Значение по умолчанию fsync поведение на OS X v10.4 было fcntl(F_FULLFSYNC) но на Leopard это - стандарт fsync. (Это влияет на все базы данных SQLite по Leopard, не только Базовые Данные.) Прагма позволяет Вам переключать это значение. См. “Конфигурирование Поведения Сохранения Хранилища SQLite” в Персистентных Функциях Хранилища полного обсуждения.

Кроме того, хранилище SQLite теперь поддерживает:

• Дополнительная генерация SQL для предикатов включая ANY и операторов IN и подзапросы;

• Опция тайм-аута на персистентном координаторе хранилища.

NSErrorMergePolicy и оптимистические записи блокировки

NSErrorMergePolicy политика заставляет сохранение перестать работать, если существуют какие-либо конфликты слияния (см. “Обнаружение конфликта и Оптимистическую Блокировку” и «Разрешение конфликтов» в Управлении изменениями). В случае отказа, save: метод возвращается с ошибкой с пользовательским информационным словарем, содержащим ключ @"conflictList"; соответствующее значение является массивом записей конфликта.

В OS X v10.4, все значения отношения в записях являются управляемыми объектами; в OS X v10.5, все отношение оценивает в записях, чтобы быть objectIDs. Это изменение назад двоичное совместимый, таким образом, это только влияет скомпилированный в OS X v10.5 и использование NSErrorMergePolicy выполнять некоторое пользовательское восстановление.

Контекст Управляемого объекта, сохраните: и commitEditing

Поведение NSManagedObjectContext save: метод изменился в OS X v10.5. В OS X v10.4, save: метод ошибочно заставил связанные текстовые представления фиксировать свои незаконченные редактирования; в OS X v10.5 эта ошибка был фиксирован.

Это означает, что, например, в Базовом нешаблоне документа Данных базировал приложения, соединенные на или после того, как OS X v10.5, для тиражирования поведения OS X v10.4 приложение делегат приложения должен отправить контекст управляемого объекта a commitEditing обменивайтесь сообщениями при сохранении.

Шаблон приложений CoreData, предоставленный XCode, включает делегата приложения, реализующего некоторые основные Базовые Данные и функциональность приложения, включая действие сохранения. Реализация saveAction: метод прост — он просто говорит контексту управляемого объекта делегата сохранять. Для пользовательских интерфейсов, создаваемых с Привязкой Какао и соединенных на OS X v10.5, это имеет эффект отбрасывания редактирования прежде, чем сделать фактическое сохранение. Для приложений, соединенных на OS X v10.4, это поведение инициировало ошибку, где связанным текстовым представлениям будут фиксировать их незаконченные редактирования вместо отброшенного.

Это было фиксировано для приложений, соединенных на или после OS X v10.5. Однако это действительно означает, что, если Вы хотите ожидать редактирования в связанных текстовых представлениях, которые будут фиксироваться во время сохранения, необходимо изменить saveAction: метод для первого вызова [[self managedObjectContext] commitEditing] (или используйте commitEditingWithDelegate:didCommitSelector:contextInfo: вариант) перед сохранением. Иначе незаконченные редактирования будут отброшены.