Comments on: How To Use Fixtures to Populate Your Database in Rails

By: Jason Boxman

Jason Boxman — Thu, 21 Aug 2008 03:40:51 +0000

I have been using seed-fu plugin lately for handling data seeding and I’ve found it to be a nice solution. I was always uncomfortable with the idea of using my testing fixtures for seeding. The best part, besides being able to key off a field (or fields) and change existing seed data attributes in production, is that it’s all just Ruby inside, not YAML.

By: Vincent Dogradi

Vincent Dogradi — Thu, 31 Jul 2008 14:35:35 +0000

Using fixtures to populate default or initial database values may cause some problem due to the way the id are generated. In fact, the id seems to be generated by calculating a hash of the fixture name.

If you use this to populate a “mutable” table (like user table for instance), you will have your sequence of id beginning to a possible (random) high value. Say if you have 1 admin user loaded from fixture with id=283156471, then all users that will be added will have consecutive id beginning at 283156472.

By: Isam

Isam — Mon, 28 Jul 2008 05:22:14 +0000

Hey Jamie,

rake db:fixtures:load is dropping the current records in your database (those created by the migrations) before adding its own data. This prevents duplicates from being added every time you run tests. You can keep the data in a fixture.

By: Jamie

Jamie — Sat, 26 Jul 2008 03:03:01 +0000

So I’ve got production data that I need in every instance of my app. The best example is a “countries” table for user selection. My take on this is to put that type of data directly in a migration. That way it lives in every instance and gets migrated appropriately.

My problem is that when I do a rake db:fixtures:load, it drops anything created in my migrations. :/ Am I doing it wrong?

By: Jeff

Jeff — Fri, 11 Jul 2008 21:59:58 +0000

Just fyi, in Rails 2.1 you can also skip the manual database creation step by doing this:

rake db:create:all

This will create all of your local databases if they don’t exist yet (i.e. only those databases in database.yml that use localhost or 127.0.0.1 as their host name).