Re: core data store type and icloud
Re: core data store type and icloud
- Subject: Re: core data store type and icloud
- From: Martin Hewitson <email@hidden>
- Date: Sun, 23 Oct 2011 07:13:46 +0100
On Oct 23, 2011, at 03:13 AM, Roland King wrote:
>
> On Oct 23, 2011, at 4:18 AM, Jens Alfke wrote:
>
>>
>> On Oct 22, 2011, at 11:59 AM, Martin Hewitson wrote:
>>
>>> -migratePersistentStore:toURL:options:withType:error:
>>> Still, the core data iCloud integration remains sufficiently mysterious...
>>
>> That method’s been around since 10.4; AFAIK it just does a “save as” operation to a new file. Is there some other documentation that says it works specially with iCloud?
>>
>> I haven’t seen anything that implies any special treatment of CoreData documents in iCloud besides just copying the entire file at once (a la Dropbox.) Did I miss something that says that iCloud will sync docs at the row/record/object level? If it does that, how does it handle sync conflicts, partial syncs, and referential integrity?
>>
>
> Take a look at the document called 'Using Core Data with iCloud Release Notes' which is in the iOS5 documentation.
OK, I have read this once, but I'll read it again. I'm not working on IOS, but I guess the core data stuff should be the same on the Mac. I'm particularly interested in figuring out how to merge the records received when getting an NSPersistentStoreDidImportUbiquitousContentChangesNotification.
> That gives quite a lot of information about how Core Data SQLite databases are supposed to work in iCloud. Indeed iCloud itself doesn't do anything much different with them, it continues to just keep files in sync, the difference here is that your Core Data SQLite store is kept locally in a directory which doesn't sync to iCloud, however the store is set up with an extra couple of keys in the persistent store options, one of which points to a log directory where there's a log file for each update to the database, and those do sync. Clearly that reduces each individual sync data usage as only one new file is copied. iCloud itself doesn't do anything with those, however when you open the store on a new device the latest logs are applied to the local database on that device, bringing it up to date. Similarly when you open a document for the first time on a new device, it creates a new local SQLite database and populates it.
OK, I wonder if that's what it does for a shoebox app as well?
>
> That's the theory at least. There's no discussion in that document about conflicts, just a small paragraph about schema changes which doesn't really give enough detail. Nor is there an explanation of what happens to a store you've been running in 'local' mode which you then move to iCloud. I don't believe that Core Data writes these log files for local stores and it's not explained how they appear when you first push the document to the cloud, as they would have to to to give a current snapshot of the database for new devices to prime the pump with.
>
> The only example I've seen is in the developer forums, in what's still called iOS5 Beta (and is probably thus still restricted although I hope that will change soon), in the iCloud section, it's sticky near the top and is called 'iPhoneCoreDataRecipies Sample Code'. People are definitely finding it frustrating and very broken at this point, especially recovery from app deletion on the device. My feeling from that thread is it's not quite ready for prime time. I took a look at Pages, Numbers and Keynote to see what they are doing, you can find the iCloud synced files on your mac, iCloud just syncs everything whether there is an application to open it or not. They use SQLite and what looks like Core Data however there are no logfiles and a bit of testing showed they just sync the whole SQLite file for each document (all 300K of it) every time. (I did wonder whether Apple would approve an app submitted by a developer which did that!).
>
> I see nowhere that SQLite is mandated, in fact the documentation talks about atomic stores and there are hooks in UIManagedDocument for creating them. UIManagedDocument out of the box does try to use SQLite and does supposedly set it up using the 'logfile' method, but I haven't tried it. iCloud integration currently only works on the device, not the sim, and I figured it would be quite frustrating to have to work through a new technology with scant documentation on the device.
>
> And finally I haven't seen a similar document in the Lion documentation. The keys which specify the logfile directories in the persistent store options exist so I've been assuming the underlying code is there, if anyone knows of a Lion document SQLite Core Data and Lion I'd love to read it. For iOS it seems fairly clear that if you use UIDocument and preferably UIManagedDocument your app is going to be quite iCloud friendly. On Lion, NSDocument seems to be the way to go but I've not yet seen an equivalent of the UIManagedDocument.
>
Thanks for all the information. It seems we are quite a way from routine iCloud integration.
Martin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: email@hidden
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden