Re: Core Data Initialization
Re: Core Data Initialization
- Subject: Re: Core Data Initialization
- From: Fritz Anderson <email@hidden>
- Date: Wed, 04 Sep 2013 09:54:06 -0500
On 4 Sep 2013, at 6:33 AM, Dave <email@hidden> wrote:
> It doesn't actually say use an Core Data SQLite file, it says use a persistent store which may or may not be the same thing. Using an SQLite file that has been created using an older version of the app is really dodgy for a number of reasons:
>
> You have to manually copy the data out of an app from the simulator or a device into your project structure. If you don't do this, if the Model Changes, it may well crash on a clean install. This will be largely hidden at the development stage.
>
> It is better to use the same source as the real application will use to build a fresh copy of the Store. In my case the live app uses JSON Server feeds to populate a Core Data Store. So, in this case all I have to do is hold local copies of the JSON files, and on a clean install (the first time the app is launched), change the URL to point to the local files, instead of the usual Server URL.
I understand you to be saying, as an absolute best practice, that apps that depend on initialized Core Data stores should generate the initial stores from raw (or reformatted) source data. Forgive me if I misunderstand.
Problem. I have to synthesize an immutable Core Data store from two .sqlite3 databases (not Core Data), totaling 300 MB, plus 6 MB of XML texts†. The TEIs include an entity to be indexed at every word. The synthesis is not simple; it involves joins of hundreds of thousands of records 3 layers deep.
† (Actually SGML/TEI, which means Foundation XML parsers are useless. And Humanities professors abuse the DTD so thoroughly that we need a file-by-file configuration for an all-purpose parser to make semantic sense of it.)
Synthesis (using NSOperation where possible) takes four or five hours on a 12-core Mac Pro. That's with local files; pulling a 350 MB database from a server would be amusing, but not practical: Most people don't have the time to replicate this process with their iOS hardware. And no, it can't be pulled in on-demand from a server.
We have another app that does something similar, but there are only 77,000 objects derived directly from 20-something XML files (which the originating department kindly converted from TEI), so it's much quicker. But still many minutes.
Of _course_ we embed complete Core Data stores in our apps. I'd call anything else insane, but I can't imagine any insane person attempting it. And MOM conflicts are not a problem: We know when our MOM changes (thankfully rarely). When it does, one of us regenerates the store. This happens every ten weeks or so. We endure the time and trouble to drag the current MOM and store into the project directory. Subsequent builds use the new MOM and the store built from it, and there is no question of data/model compatibility (unless we forget, which turns up instantly).
Mac-generated stores are completely compatible with iOS Core Data. There is no reason to have the Simulator do it.
Migration of user-mutable stores is quite another matter, but that problem is unavoidable, and there are known techniques for addressing it. My guess is that migration is almost always a less-intensive process.
Now, I am abusing the point you are making. You probably had it in mind that there are extreme cases where your approach isn't possible. But it should be on the record that there are many cases in which the solution you posed as universal isn't possible.
— F
_______________________________________________
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