I am deploying a rails app to nginx.
There are many migrations in the development stage.
How to create the production schema in a simple way instead of reading many migration.rb files ?
Because I deleted several migration files during develepment. Now when deploy production environment it shows me some errors
Thanks
You can use the schema.rb file (via rake db:schema:load), but beware it will drop all existing tables. If you have existing data you will lose it.
Once you load the schema then it sets the database version, so only new migrations that are created after the schema file was created will run in the future.
Here is some info for Rails 4.2 about schema dumping:
Schema Dumping and You
Related
I'm new to rails, and I accidentally ran rails db:rollback command in a development.
Next I did rails db:migrate:up VERSION=XXXX to change status of the file I rolled back from down to up.
The migration file was about images. However my images were gone in a development mode due to rollback, files status the same as before I ran rails db:rollback.
In this case, if I pushed this to remote repository, and it's merged in production, the images already there will be gone as well as mine in development?
When add_column method in migration is run you just add column in migration so it will run for production & development environment. Now you added images through localhost to your application and stored in database. So those will be stored to database regardless migration.
Rollback will remove column running remove_column so it will hamper your development as removing column will make you loose all data inside column of table. So on production it does not deal same.
Images are getting pushed to production database or remote repository, it is just to add or remove column only so rollback will affect only your local/development
Unless you're doing something wacky in your migrations, any goofs like this you make to your development database will not effect production. That's why dev and prod databases are separate.
The general problem of "is it safe to push to production" can be mitigated by adding a staging server which runs in the production Rails environment, but is used for additional manual testing of new features. Once everything checks out in staging then push to production. Many services provide a "pipeline" to do this for you, for example Heroku Pipelines.
When working on a project, I keep track of all the changes I make to a database in a notepad file. Then, later, I manually write all the changes in rails' db migration file.
But it should be possible to compare the schema of a backup of my database, with the new version of my database, and automatically detect the differences. And generate the rails db migration file automatically.
Is there a tool that can compare two database schema's and automatically generate rails' db migration files?
As far as I'm aware, there's no tool that will do it automatically, however, you can get most of the way there just using rake db:schema:dump with source control.
Create a new Rails project and do the following:
Update database.yml to connect to your first database.
Use rake db:schema:dump to populate schema.rb and commit schema.rb to git.
Update database.yml to connect to your second database and again run rake db:schema:dump
Use git diff on schema.rb to compare the changes. This can easily be mapped to a migration.
The benefit of using source control is that you can then test the migration by comparing schema.rb after the migration runs to the schema dump of the second database.
I'm working on a rails application where we made changes to the schema directly without writing migration files. Now I want load the schema in the development machine to Staging server. But if I did rake db:schema:load, It will erase the data in the database.
Is there anyway to solve this problem? I want to restore the data in the table after running rake db:schema:load.
We have a legacy PostgreSQL database that is perfectly accessible from a Rails app except that when the vendor provides an update one of the consistency checks they perform against the database fails because Rails has built a "new" table there, the schema migrations table. Is it possible to direct creation of this table elsewhere? Or is it possible to use the schema cache in Rails 4 to effect this? The release notes section 3.3 on General things says "Schema cache dump (commit) - To improve Rails boot time, instead of loading the schema directly from the database, load the schema from a dump file."
I found an old blog post about this last time I tried it here. Copying the relevant parts:
To make a dump of your schema, execute the following rake task:
RAILS_ENV=production bundle exec rake db:schema:cache:dump
This will generate a file db/schema_cache.dump, that Rails will use to load the internal state of the SchemaCache instance.
To disable the schema cache dump, add the following to your config/production.rb file:
config.active_record.use_schema_cache_dump = false
If you would like to clear the schema cache, execute:
RAILS_ENV=production bundle exec rake db:schema:cache:clear
I just deployed my rails app to a Linode VPS, and was wondering what would be the best way of adding records to the DB.
I have tables such as Categories, which I'd like to populate.
I thought of the Taps gem, using a csv, or an sql dump file.
I'd like to know if there are any tools out there for this?
Thanks
For this puporse there are the so called seed file which is default in:
db/seeds.rb
You can add entries here ( there is an example in the seed file ), which you can generate after deployment with a rake task:
rake db:seed
You probably are using bundler as well, so use:
bundle exec rake db:seed
In case of large number of seeds you can always create multiple files, see this blogpost about handling large seed files.
However, if you are in a state, where the already existing data in the app is crucial and you are changing servers or database drivers you wanna take a look on yaml_db gem which gives a nice method to abstract the existing data away from your actual db driver and export it into a .yaml file which you can import later back e.g.: after deploying on a new server.
See Railscast - #179 about seeding.
The rails way would be to use seed data in db/seeds.rb and then populate it by using rake db:seed.
You could also use a sql dump file and restore by issueing mysql -u <user> -p <database_name> < <mysql_dump_file>
The Easy Reference Data gem is similar to db:seed, but will update records if entries already exist. It also has easy integration with Capistrano.
Full disclosure: The company I work for developed the gem.