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: "email@hidden" <email@hidden>
- Date: Fri, 29 Jan 2010 21:01:54 +0000
On 29 Jan 2010, at 20:10, Matt Neuburg wrote:
> 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?
I think using a command line tool is doable for this.
But is there any reason not to just to build another simple cocoa app that does the same thing?
That way you can maintain the familiar bundle structure and probably won't have to futz so much with coredata.
Regards
Jonathan Mitchell
Developer
http://www.mugginsoft.com
>
> Thx - m.
>
>> Matt Neuburg <mailto:email@hidden> wrote (Wednesday, January
>> 27, 2010 10:11 AM -0800):
>>
>>> Here's my problem. Tell me how to structure my project to handle it. The
>>> issue, in a nutshell, is that my data starts life as text files but in my
>>> shipping app the data is expressed as a Sqlite database. So there are two
>>> steps when I build my app:
>>>
>>> Step 1:
>>>
>>> I have a bunch of text files. I read them and parse them into a Core Data
>>> in-memory store. Then I switch the store to a Sqlite store and save out the
>>> database.
>>>
>>> Step 2:
>>>
>>> I build my real app. It contains the database - not the text files - and
>>> uses pure normal Core Data Sqlite store procedures.
>>>
>>> The way that I originally solved this problem works but isn't easily
>>> maintainable. I didn't quite know where I was heading with this, so I didn't
>>> plan very cleverly. I have just one target. What I did involved building and
>>> running my single target twice, with adjustments to the code and the target
>>> structure in between.
>>>
>>> So, the first time, the text files were included in the target; I build and
>>> run the app, the app starts up, reads the text files from inside its own
>>> bundle, saves the Sqlite database, and quits. Then I remove the text files
>>> from the target, add the database to the target, comment out a bunch of
>>> code, uncomment some other code, and now we've got the target for the "real"
>>> app that I ship.
>>>
>>> So my real app depends upon a sort of "pre-app" that must not only be built
>>> but must actually be *executed* in order to generate the database as an
>>> intermediate product. How should I express this entire two-step dance as a
>>> single build operation? Thx - m.
>>>
>>
>>
>>
>>
>>
>
> --
> matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
> A fool + a tool + an autorelease pool = cool!
> AppleScript: the Definitive Guide - Second Edition!
> http://www.tidbits.com/matt/default.html#applescriptthings
>
>
>
> _______________________________________________
> 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
_______________________________________________
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