I am in the process of packaging a rails application as an RPM, and I
have a few questions regarding the initialization of the database
environment.
As part of the post-install script, I need to check to see if the
database exists. Depending on the outcome, I may have to run various
combinations of db:setup, db:migrate, and/or db:seed. Is there a rake
(or some other) task I can run to check for the existence of the
“production” database? If not, is there a “standard” way to fetch the
database name for the production environment from the database.yml
file so I can use external tools?
What I’m thinking about doing is defining the default user, password,
and database name as macros/constants in my .spec file. When I build
my RPM, I will use sed to generate database.yml with these pre-defined
values so they are consistent between my initialization scripts (in
the spec file) and the database configuration included in the
package. This would work perfectly with a new installation.
The problem with this approach is with upgrading an existing
installation. Since database.yml is a configuration file, I have to
assume that the database.yml file has been modified and that my
“defaults” no longer match the production values. I need a simple way
to ask rails “does my production database exist?”.
On Thu, May 5, 2011 at 6:45 AM, jcwoods [email protected] wrote:
file so I can use external tools?
assume that the database.yml file has been modified and that my
“defaults” no longer match the production values. I need a simple way
to ask rails “does my production database exist?”.
If you’re rails environment variable is set to production
(RAILS_ENV=production) then you can run db:create followed by
db:migrate. If
the db already exists then db:create will do nothing. If the migration
is up
to date then db:migrate will do nothing.
B.
Is it better to do db:setup + db:seed or db:migrate for a fresh
install? By my understanding, the seed data is not applied during a
db:migrate. (This is not an application I have developed, and I am
not a Ruby/Rails developer, so please excuse my ignorance!)
Right, but my point was doing db:setup (or db:schema:load) and db:seed
is dependent on whether the database exists or not at the time the
package is installed. This goes back to my original post – how do I
detect if the database is there if db:create succeeds either way?
If I didn’t have seed data, this would be a moot point since I could
do db:create + db:migrate every time. Or am I missing something?
Put in other words, this is what I’m trying to do:
if ! database_exists; then
rake db:create
rake db:migrate
rake db:seed
else
rake db:migrate
fi
It’s the “database_exists” logic that I’m trying to get a handle on.
I understand (from your last post) that I could do this instead:
rake db:create
rake db:migrate
Regardless of whether the database is there or not, but my seed data
would not be loaded.
On Thu, May 5, 2011 at 8:32 AM, jcwoods [email protected] wrote:
Is it better to do db:setup + db:seed or db:migrate for a fresh
install? By my understanding, the seed data is not applied during a
db:migrate. (This is not an application I have developed, and I am
not a Ruby/Rails developer, so please excuse my ignorance!)
Just run rake db:setup. That will create the db, load the schema for it,
and
then load the data found in the seeds.rb file all in one command. If you
want to break it out into steps that you have more control over it would
be
the following in order:
db:create
db:schema:load
db:migrate
db:seed
B.
On 5 May 2011 17:42, jcwoods [email protected] wrote:
Right, but my point was doing db:setup (or db:schema:load) and db:seed
is dependent on whether the database exists or not at the time the
package is installed. This goes back to my original post – how do I
detect if the database is there if db:create succeeds either way?
If I didn’t have seed data, this would be a moot point since I could
do db:create + db:migrate every time. Or am I missing something?
You could write the seed code (db/seeds.rb) so that it works out for
itself, based on whether the db is empty or not, or whether some
particular data is present, whether to do the seeding. Then you can
just run it.
Colin
On Thu, May 5, 2011 at 11:42 AM, jcwoods [email protected] wrote:
Right, but my point was doing db:setup (or db:schema:load) and db:seed
is dependent on whether the database exists or not at the time the
package is installed. This goes back to my original post – how do I
detect if the database is there if db:create succeeds either way?
If I didn’t have seed data, this would be a moot point since I could
do db:create + db:migrate every time. Or am I missing something?
You’re missing why I said you can do one or the other. Running db:setup
will
create the database if it does not exist just like db:create will do.
You
don’t need to check for the database because those commands do it for
you.
If those commands find there is not database it will create one for you.
You
will have a database to seed data into.
Put in other words, this is what I’m trying to do:
I understand (from your last post) that I could do this instead:
rake db:create
rake db:migrate
Regardless of whether the database is there or not, but my seed data
would not be loaded.
The database will be there. The seed will be run after the database
creation
if the database does not already exist. Do either this:
db:create
db:schema:load
db:migrate
db:seed
or this:
db:setup
and your work is done. There is no need to check or wrap it with
anything
else because if the database doesn’t exist it will create it for you.
B.
On 5 May 2011 21:53, Bryan C. [email protected] wrote:
…
You’re missing why I said you can do one or the other. Running db:setup will
create the database if it does not exist just like db:create will do. You
don’t need to check for the database because those commands do it for you.
If those commands find there is not database it will create one for you. You
will have a database to seed data into.
I may be wrong but I think the OP’s problem is that he wishes to not
run the seed if the database already exists. If so then he can handle
that by testing the db in the seed code itself as I suggested in
earlier post.
Colin