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: > > 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 <[email protected]> wrote: > > 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 May 5, 8:55 am, Bryan Crossland <[email protected]> wrote: > > > > On Thu, May 5, 2011 at 6:45 AM, jcwoods <[email protected]> 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 [email protected] > . > > > To unsubscribe from this group, send email to > > > [email protected]. > > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
