Объяснение NSIncrementalStore на английском языке

Ответ 1

ПРИМЕЧАНИЕ: этот API был омрачен, когда я написал это в 2012 году, и детали изменились. Не стесняйтесь обновлять это, если хотите. На данный момент я не работаю над любыми проектами Cocoa/ObjC, поэтому, к сожалению, я не очень хороший человек, чтобы держать его в курсе последних событий. Кажется, что общий смысл верен.

Core Data предоставляет набор инструментов, которые помогают управлять сохранением объектов, т.е. возможностью сохранять, а затем возвращать наборы объектов (NSManagedObject) из какого-либо хранилища.

Когда вы работаете с объектами Core Data, вы делаете это с помощью NSManagedObjectContext, который вы получаете из NSPersistentStoreCoordinator. В свою очередь, PSC ведет переговоры с одним или несколькими подклассами NSPersistentStore, которые обрабатывают фактические операции в хранилище. (Подумайте о создании/чтении/обновлении/удалении по базе данных.)

Core Data поддерживает два основных типа хранилища: NSPersistentStore и NSAtomicStore. Постоянное хранилище можно рассматривать как базу данных: вы можете инкрементно сохранять, обновлять и извлекать из него произвольные наборы записей. Атомный магазин представляет собой "все или ничто" представление графа объектов. Он предназначен для представления структурированного файла в памяти.

Типы хранилища, с которыми связаны Core Data:

• NSSQLLiteStoreType (NSPersistentStore)
• NSInMemoryStoreType (NSPersistentStore)
• NSXMLStoreType (NSAtomicStore)
• NSBinaryStoreType (NSAtomicStore)

NSPersistentStore явно запрещается быть подклассом, поэтому до сих пор не было никакого способа создать собственный собственный неатомный бэкенд. То есть, если вы хотите сохранить и запросить представления ваших объектов по частям, а не в одном большом компе ( "загрузить весь график", "сохранить весь график" ), вам не повезло. До появления iOS5 NSIncrementalStore.

NSIncrementalStore - это абстрактный класс (от NSPersistentStore), методы которого вы реализуете, чтобы обеспечить адаптер между хранилищем данных, который вы контролируете, и мир основных данных. Вы можете использовать его для переноса удаленного API, или если бы вы были так склонны, вы могли бы обернуть что-то вроде NULevelDB или NanoStore (хотя я не уверен, почему вы это сделаете).

Ответ 2

Вы использовали бы NSIncrementalStore для доступа к удаленному серверу через Core Data. Вместо того, чтобы читать и записывать в локальный файл, вы должны направить запрос на сервер и получить ответ, который вы нажимаете на Core Data. Аналогично для сохранения и т.д.

Обратите внимание, однако, что это нетривиально. Это очень мощная функция, но, если вы не являетесь экспертом в области использования основных данных, я бы сильно отговаривал ее, так как есть бесконечные возможности стрелять в ногу, если вы не знаете много о том, как взаимодействие Core Data с уровнем хранения работы.

Если использование uploaded решает вашу проблему, тогда сделайте это.

Ответ 3

Вкратце, если вы используете хранилище SQLite с вашими основными данными, вы уже используете инкрементное хранилище. Все преимущества инкрементных магазинов (т.е. В основном, не загружая весь магазин в память) уже находятся в вашем распоряжении.

Что касается конкретного применения API NSIncrementalStore, я бы предложил сначала определить, какую именно проблему вы хотите решить. Если вам нужен этот API или нет, это будет определяться конкретными потребностями вашей задачи программирования.

EDIT в ответ на редактирование вопроса

Я бы просто сделал это так: в ваших объектах Core Data на устройстве вы можете иметь атрибут BOOL uploaded. Когда веб-служба станет доступной, запустите загрузку и вытащите все объекты, а не uploaded.

Чтобы загрузить, преобразуйте свои объекты в NSArray и NSDictionary, возможно, в формат JSON и POST на свой веб-сайт. Когда веб-сайт отвечает, что он сохранил данные, отметьте все объекты как uploaded.