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?". -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Thu, May 5, 2011 at 6:45 AM, jcwoods <jcwoods-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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?". >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.>-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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!) On May 5, 8:55 am, Bryan Crossland <bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Thu, May 5, 2011 at 6:45 AM, jcwoods <jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > 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?". > > 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. > > > > > > > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Thu, May 5, 2011 at 8:32 AM, jcwoods <jcwoods-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 May 5, 8:55 am, Bryan Crossland <bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > On Thu, May 5, 2011 at 6:45 AM, jcwoods <jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > 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?". > > > > 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. > > > > > > > > > > > > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 May 5, 9:46 am, Bryan Crossland
<bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> On Thu, May 5, 2011 at 8:32 AM, jcwoods
<jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 May 5, 8:55 am, Bryan Crossland
<bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Thu, May 5, 2011 at 6:45 AM, jcwoods
<jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > 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?".
>
> > > 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.
>
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "Ruby on Rails: Talk" group.
> > To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To unsubscribe from this group, send email to
> >
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > For more options, visit this group at
> >http://groups.google.com/group/rubyonrails-talk?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On 5 May 2011 17:42, jcwoods <jcwoods-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Thu, May 5, 2011 at 11:42 AM, jcwoods <jcwoods-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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:> > 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. > >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 May 5, 9:46 am, Bryan Crossland <bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > On Thu, May 5, 2011 at 8:32 AM, jcwoods <jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 May 5, 8:55 am, Bryan Crossland <bacrossl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > On Thu, May 5, 2011 at 6:45 AM, jcwoods <jcwo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > 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?". > > > > > > 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. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Ruby on Rails: Talk" group. > > > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > . > > > To unsubscribe from this group, send email to > > > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > > For more options, visit this group at > > >http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 5 May 2011 21:53, Bryan Crossland <bacrossland-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.