Re: project structure for two-stage core data build
Re: project structure for two-stage core data build
- Subject: Re: project structure for two-stage core data build
- From: James Bucanek <email@hidden>
- Date: Fri, 29 Jan 2010 22:46:08 -0700
Matt Neuburg <mailto:email@hidden> wrote (Friday, January
29, 2010 1:10 PM -0800):
On Thu, 28 Jan 2010 09:28:46 -0700, James Bucanek <email@hidden>
said:
create a Core Foundation command-line tool that
converts the text file into the database. You've now a
stand-alone DB compiler.
This sounds cool, but my eyes are a little glazed over. As I explain in my
Step 1 summary (quoted below), I parse the text files into a Core Data
store. Well, Core Data uses a compiled data model (a .mom file). In a
full-fledged app, the .mom file is in the app bundle's Resources folder. But
a command-line tool has no Resources folder - has it? So there isn't any way
to do these Core Data manipulations in a command-line tool - is there? Of
course I'm hoping I'm just wrong, so don't hesitate to set me straight.
Maybe the .mom file has some other purpose and isn't needed here.
I'm having the same sorts of mental issue with the text files themselves. In
a full-fledged app, I know where they are because they've been copied into
the bundle. But how will the command-line tool know where they are?
As Jonathan Mitchell suggested, your solution might be most
easily met by writing a stand-alone Core Data Cocoa app that
simply compiles the text file, writes the Core Data store, and
quits. Sometimes the "best" solution is the one that works. ;)
To answer your specific question, if you wanted to create this
as a tool one approach would be turn it into a plug-in style
bundle. That would let you still package your .mom and source
text files as part of the bundle, where your code can easily
find them, without creating an application.
To create a Foundation tool you'd have to locate your source
text file, compiled .mom file, and other resources using
something other than the regular bundle methods. When a target's
build script phase, or a custom compile rule, executes it is
passed a set of environment variables that tell it where the
source files are located, the path the project, the path to the
output files directory, and so on. You'd structure your code to
use these variables (instead of searching your bundle) to locate
the appropriate files.
It really all depends on how efficient you need this to be, how
reusable you want the solution, and how much work you're willing
to put into it. A Core Data Cococa app that simply launches,
compiles, and quits will probably give you 90% of what you want.
The only real disadvantage that I see is that it won't be as
fast a command-line tool that does the same thing. This may, or
may not, be a big deal.
Note: If you go the Cocoa app route, launch the app in the
script phase using the 'open' command and pass the -W
(wait-until-exited) option. Otherwise, the build phase will
continue before the application is finished.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden