I've been working on a rails project, in which I need to firstly seed the database and then update the data periodically.
The unfortunate problem is that I seem to want to update the same set of data multiple times. Hence I would like to use the same migration name...but the rails generator seems to complain about the naming.
This leads me to a couple of questions.
Should I even be using migrations to update data in my db or is there an alternative?
How do I get around the naming problems, my assumption was that the timestamp that prepends itself to the migration name would be an adequate differentiating factor?
Thanks
A while back developers used the migration for seeding data. Such was the importance of this need as a core feature and the perceived uncleanliness of this approach, Rails 2.3.4 introduced a dedicated rake task for doing this.
This is now best practice. See this post and this screencast for more info.
For periodic db updating you can add a custom rake task to lib/tasks which works well in my experience.
Related
In my application, I have users and roles. Some of the roles should always exist, such as "Admin". Where should I do something like:
Role.create(name: 'Admin')
In the past, I've always placed these lines in a migration to ensure it ends up on the deployed server. This sometimes leads to issues as a developer may forget to instead write it like:
Role.where(name: 'Admin').first_or_create
Should they go in the seeds.rb file? I have generally used the seeds file for local development "playing around" data.
What is the Rails Best Practice for generating static data?
The seed.rb is the perfect place for that. Migrations are not meant to be used for anything other than convenience during development and should never be relied upon for really anything.
From the docs:
To add initial data after a database is created, Rails has a built-in
'seeds' feature that makes the process quick and easy. This is
especially useful when reloading the database frequently in
development and test environments. It's easy to get started with this
feature: just fill up db/seeds.rb with some Ruby code, and run rails
db:seed
http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
Rails way is to use seeds.rb - simple and useful.
In my opinion, data migrations are needed only in situations when you must add data to existing records (after inserting new column with default value, for example)
Happy New Year everyone.
In my Rails 4 application I have a table plans containing the records for the plans that a user can subscribe to.
It is absolutely paramount for the app that this table is populated at any time, in development, test, and production mode. Otherwise the app will not work.
What is the best way to create those records?
Should I put a create method into an initializer? Or set up a rake task and run it manually whenever I restart the server (sounds a bit cumbersome, though)?
Thanks for any help in this matter.
Rails has a 'seeds' feature that should be used for seeding a database with initial data.
It's a really simple feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed
source: http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
If you want to use data in your test environment, you might also be interested in using fixtures for your plans. Take a look at http://guides.rubyonrails.org/testing.html#the-low-down-on-fixtures
I want to create a Rails app but I have a question before start it.
I have defined a database model in paper (about 15 tables) and I don't know which is the best way to start the application:
Create the tables on database with my database client and after that in console do:
rake db:schema:dump
with this I will obtain the shema.rb and after that do a :
rake db:migrate
or
In console, one to one, create the models, edit them with an editor and do:
rake db:migrate
I think the first one is more quickly but the second I think is better from the point of view of rails.
I am bit confused about that, can anyone help me with this question?
Rails mean the only sure way to create a database for a new application - migration.
You can create a single migration for all of your application but such migration is not easy to roll back.
Therefore wise to create a migration for each table.
Normal situation when you have 100,500 migrations in the end. For that you get your application is ready for deploy to combat server.
Permitted the creation of migration through model and scaffold or independently.
Why not use a generator?
rails g model User first_name last_name age:integer email user_name
You don't need to specify type if it's string. This will generate model class and migration.
I think there may be varying viewpoints on this issue.
Also, it depends if you're using the rails built-in sqlite database.
However, assuming that you do use the default rails db configurations,
I personally prefer the second choice.
Later, you might want to change some parts in your tables.
If you follow the rails way of doing so, this process will be very easy and less confusing.
Also, you can always add custom ruby scripts for pre-loading with data.
Of course, other people might find the other way easier.
I have an existing database in which I am converting a formerly 'NULL' column to one that has a default value (and populating that with said default value). However, that value is an ID of a record I need to create. If I put this record in db/seeds.rb, it won't run because db/seeds.rb runs after migrations -- but the migration needs seed data. If I leave the record creation in the migration, then I don't get the record if I make a fresh database with db:load. Is there a better way other than duplicating this in both db/seeds.rb and the migration?
Thanks!
While I can understand your desire to stay DRY and not have to write this in both the migration and seeds.rb, I think you should write it in both places. Not just to make it work, but to accomplish different requirements related to your problem.
You need to ensure that your migration can execute properly regardless of external processes. That means you should put any code required within that specific migration. This isn't to accomplish anything besides making sure your migration executes properly. Suppose someone else tries to migrate without knowing you put part of the code in seeds.rb, it would be very difficult for them to figure out what's going on.
You can make db:load work properly by including similar code in seeds.rb. However, you should be evaluating the current state of your database in seeds.rb due to the fact that it runs after the migrations. So you can check to see if the column exists, and what the default value is etc. This means that if the migration ran and took care of everything, seeds.rb doesn't repeat work or modify values inappropriately. However, if the migration did not set these variables as expected, it is able to set the values.
I'd recommend looking at it as two separate issues so you can be more confident of each one executing successfully independent of one another. It also creates better maintainability for understanding by yourself or others of what's happening in the future.
In my opinion you should treat this in both db/seeds.rb and the migration.
The migration is used to get an existing database from an older version to another version while seeds.rb and schema.rb are used for a fresh database with the latest version.
I'm switching to RoR from ASP.NET MVC. Yeah, migrations are cool, but I do not need to use different databases in my web applications. Postgresql will do just fine.
So is it okay if I use PGAdmin to create and administer my databases and schema and avoid all these fancy migrate, rake etc?
Update
Thanks everyone! Now I better understand what migrations are, and why I should use them.
I don't think that's what migration means.
Migrations in rails (and in other frameworks) is a method by which you can use to update your database schema when there are multiple versions of the same database running
For example, you may have two databases, one running on your production server, and another running locally for development. After a few days of coding, your local development database may looks a bit different. With migrations, you can simply push your code to the production server and then run the migrations to automatically update your production database so it is up-to-date with the one you use locally for development.
So, to answer your question, Yes it is OK but you might not get a few of the migrations niceties when the time comes that you'll have to maintain multiple versions of your database.
Have to agree with charkit but one (rather two) important note why you should use migrations: Migrations don't make up the model definitions. They are stored seperately in a file schema.rb. This defines the rows and tables of your database. When looking into the file, you find these lines:
This file is auto-generated from the current state of the database. Instead of editing this file, please use the migrations feature of Active Record to incrementally modify your database, and then regenerate this schema definition.
The second reason is for testing: you can easily set up a test database to run all your tests against without the need to touch the "real" database. I know when developing, this is not a big problem but this will get more important after some time.
So, yes, it is possible to use PGAdmin to create all your database related stuff but you should not forget to always keep the schema file up to date and come up with a solution for testing.
With migrations you're able to develop your database schema in Ruby and this is usually database indpendent.
In short, spend the 20 minutes or so to really get migrations and the value they add. Then determine whether or not you want to ditch them. Strangely for me I learned Rails before I started my first MVC project; one of the things I missed most was migrations.
From a technical standpoint you should be fine without them.