Re: Doing database creation before EOF gets involved ?
Re: Doing database creation before EOF gets involved ?
- Subject: Re: Doing database creation before EOF gets involved ?
- From: Theodore Petrosky <email@hidden>
- Date: Thu, 30 Jan 2014 20:36:19 -0500
I have thought about this a bunch of times. My DB of choice is Postgresql. When you create the database cluster, PG automatically creates at least two databases. Template1 and the basis of Template1.
I have often thought it would be possible to first let my app connect to Template1 as it must exist for PG to function. Then I could issue the SQL directly in my first migration that creates the database that I want.
step two would be to then diddle the connection dictionary to point to the correct database.
now normal migrations take over to create the tables, relationships, etc.
I don't know that this would work. It was only an idea I had whilst driving to WOWODC13. It's a long drive from NYC to Montreal and what else is there to think about.
If someone that understands this at a deeper level, put me out of my misery.
Ted
On Jan 30, 2014, at 6:40 PM, Gavin Eadie <email@hidden> wrote:
> I'm working on a WebObjects project which uses a database of minor complexity, and am wrestling mentally with finding a good way to let the first run create the database.
>
> Currently, the first run needs the EOModel's connection record to find the database (which is created my hand, but empty), and then uses Migration to read a SQL file that creates all the tables and fields. But I want a kind of "turn-key" start where, if the database doesn't exist, it gets created.
>
> My thinking so far has taken me to consider catching the exception that the missing database causes, using bare JDBC calls to create the database, and then, somehow, resuming use of the EOModel.
>
> But I learned years ago that if things are getting complicated in the WO/EOF world, I'm not doing it right; maybe there are tricks in the heart of Wonder that would help with this? I'd much appreciate any helpful ideas to carry this plan forward (or the suggestion to abandon it because it's an unnatural act!).
>
> Thanks .. Gavin
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev 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.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden