On 4 Sep 2013, at 6:33 AM, Dave <d...@looktowindward.com> 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
