Rake Tasks: db:seed vs. dev:prime
Rake Tasks: db:seed vs. dev:prime
Using rake db:seed, which is already built into Rails, may seem preferable to using a custom rake task like rake dev:prime. However there's a time and place for both.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
In suspenders, we have a rake task called
dev:prime that allows us to seed the database with information. We’re often asked why we prefer a custom task over using
rake db:seed, which is already built into Rails. Let’s talk about a few of the differences.
We reserve the
db:seed tasks specifically for data that must be present for your application to function in any environment. One example of this may be a list of U.S. states in your database that your address form relies on. That data should always exist, whether the app is being used in development or production.
Working on an app is easier if you have data that looks and feels similar to what your users see. If you’re new to the codebase or new to a specific feature, having data preloaded that makes sense and sets you up for the feature, is really helpful.
Our development seeds contain data that are necessary for users to view most of the features of the app. They’re very convenient for developers or designers who are running the app locally. If you were building a multi-user blogging application, your seeds file would likely generate the following:
- An admin user
- 2-3 normal users
- Enough posts to ensure you have pagination (most likely, you’d want to space out their published date enough that you could also test the features to view posts by month or year)
- 5-10 comments on each post with various authors including anonymous authors
- 2-3 deleted posts
As you’re building a new feature, if it requires special data to setup, put it directly into the seeds file instead of adding it with the web interface or the console. For example, if you’re building a feature to make sure that posts without a
published_at value are not visible on the homepage, add that to your development seeds instead of creating one through the UI. This ensures that the next person who needs to test that feature has it ready to go without as much work.
For database seeds, we do not recommend using FactoryGirl to generate your data. For generating data for your local development environment, however, it can be very helpful to leverage your test factories to simplify setup. For building a lot of blog posts you could rely on the defaults for most fields but randomize a few key fields:
if Rails.env.development? || Rails.env.test? require "factory_girl" namespace :dev do desc "Sample data for local development environment" task prime: "db:setup" do include FactoryGirl::Syntax::Methods titles = [ "You won't believe what we found out about cheese!", "Don't skip these 12 super foods", "Only 20s kids will remember these toys", ] authors = [ "Liz", "Sam Seaborn", "The Honorable 3rd Duke of Long Names", ].map do |name| create(:user, name: name) end 50.times do create( :post, author: authors.sample, title: titles.sample, published_at: (1..365).to_a.sample.days.ago, ).each do |post| (1..10).to_a.sample.times do create(:comment, post: post) end end end create_list(:post, 3, deleted_at: (1..10).to_.sample.days.ago) end end end
Development seeds are another form of communication. Reading the tests can expose a great deal of information about an app and your development seeds can provide a similar benefit. If you treat them with care, they can provide a great way to onboard new teammates as well make feature development and bug fixes easier for your existing teammates.
Published at DZone with permission of Jason Draper , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.