Базовая структура хранилища данных с несколькими хранилищами - PullRequest
9 голосов
/ 15 июня 2009

Базовые данные позволяют вам добавить несколько постоянных хранилищ к одному имени NSPersistentStoreCoordinator (каждое со своей конфигурацией), объединяя их в одно NSManagedObjectContext. Я не смог выяснить, как Core Data обрабатывает атомарность операции сохранения для нескольких хранилищ.

Допустим, у меня есть два магазина:

NSPersistentStoreCoordinator *coordinator = [[NSPersistentStoreCoordinator alloc] init];
[coordinator addPersistentStoreWithType:type configuration:@"A" URL:aURL options:nil error:NULL];
[coordinator addPersistentStoreWithType:type configuration:@"B" URL:bURL options:nil error:NULL];

NSManagedObjectContext *context = [[NSManageObjectContext alloc] init];
[context setPersistentStoreCoordinator:coordinator];

А потом пришло время сохранить, я делаю это:

NSError *error = nil;
BOOL result = [context save:&error];

В документации указано, что последовательность событий будет такой:

  1. Сохранить магазин A
  2. Сохранить магазин B

Что, если хранилище A сохраняет правильно, но хранилище B не может сохранить по какой-то причине? (например, файл на диске был удален или разрешения сделали его доступным только для чтения, такого рода вещи). Я не могу найти какую-либо документацию, детализирующую, будут ли Core Data откатывать изменения для сохранения A.

Мне кажется странным, что граф объектов был бы оставлен в несогласованном состоянии (то есть один магазин обновлен, а другой нет), но несколько сложнее и ресурсоемко, чтобы выполнить полностью атомарную экономию в нескольких хранилищах. Хотелось бы получить некоторые пояснения, возможно, от кого-то с большим опытом работы с системой!

Ответы [ 3 ]

5 голосов
/ 19 сентября 2011

Я наконец наткнулся на ответ сегодня в CoreDataErrors.h. Есть код ошибки:

    NSPersistentStoreIncompleteSaveError             = 134040, // one or more of the stores returned an error during save (stores/objects that failed will be in userInfo)

Так что, похоже, что Core Data не будет пытаться откатывать сохранения из тех хранилищ, которые действительно были успешными. И действительно, не может обеспечить атомарность в нескольких магазинах. Достаточно справедливо!

1 голос
/ 22 июня 2009

Это звучит как нечто, на что нетрудно получить экспериментальный ответ, воссоздав свои условия - было ли у вас время для воссоздания сценария, который вы наметили?

Я бы сделал это следующим образом:

  1. создание двух хранилищ sqllite и запись набора данных в каждый из файлов.
  2. закрытие магазинов
  3. удалить второй файл sqllite
  4. выписать легко видимую операцию в первом хранилище (лучше всего сделать вставку в одну таблицу и удалить из другой). Объедините это с другой операцией во втором хранилище, которая должна завершиться ошибкой из-за отсутствия файла 5.Проверьте состояние первого магазина.

Мне кажется, что изменения в хранилище А не будут отменены, но я буду впечатлен любым другим ответом.

0 голосов
/ 19 августа 2011

Один из вариантов выполнения транзакций между несколькими источниками данных известен как «двухфазная фиксация». http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Системы двухфазной фиксации обычно встречаются в разработке предприятия, иногда встроенные в системы обработки транзакций. http://en.wikipedia.org/wiki/Transaction_processing_monitor

такие как смокинг http://en.wikipedia.org/wiki/Tuxedo_(software)

CoreData на самом деле не является инструментом объектно-реляционного отображения предприятия, и я не верю, что он способен к двухфазной фиксации. Некоторые типы хранилищ, которые поддерживает CoreData, а не транзакционные или атомарные. Для поддержки двухфазной фиксации необходимо, чтобы каждое постоянное хранилище было транзакционным и атомарным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...