The Artima Developer Community
Sponsored Link

Ruby Buzz Forum
Two tips for working with databases in Rails

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Jamis Buck

Posts: 184
Nickname: minam
Registered: Oct, 2004

Jamis Buck is a C/Java software developer for BYU, and hacks in Ruby for fun.
Two tips for working with databases in Rails Posted: Dec 13, 2005 6:57 PM
Reply to this message Reply

This post originated from an RSS feed registered with Ruby Buzz by Jamis Buck.
Original Post: Two tips for working with databases in Rails
Feed Title: the buckblogs here
Feed URL: http://weblog.jamisbuck.org/blog.cgi/programming/index.rss
Feed Description: Jamis Buck's corner of the blogging universe. Mostly about ruby, but includes ramblings on a variety of topics.
Latest Ruby Buzz Posts
Latest Ruby Buzz Posts by Jamis Buck
Latest Posts From the buckblogs here

Advertisement

First tip: I’ve found recently that if I have a boolean field in the database that is being used to mark whether some event occurred (referrals.pending, or feeds.subscribed) it is often more effective to make the field a datetime and record the moment that the event occurred. Then, a NULL can be used to indicate that the event has not yet occurred. Thus, you have referrals.applied_at with a method on Referral like this:

1
2
3
  def pending?
    applied_at.nil?
  end

This gives you the capability down the road to not only report whether the event occurred, but how frequently over various periods of time.

The second tip is handy when you’re working on a migration. I find that the process (for me) works like this:

  • Create the migration and run it.
  • Discover I forgot something.
  • Migrate down to the previous schema version.
  • Change the migration and run it again.

(Repeat as necessary.) However, being the imperfect programmer that I am, I find that I often implement the #down method incorrectly, forgetting to drop a table or remove a column. Thus, when I try to run the migration again, it fails saying that the table/column already exists.

Using script/console and ActiveRecord::Schema, it becomes a cinch to clean up the artifacts:

1
2
3
4
5
  ActiveRecord::Schema.define do
    drop_table :foos
    remove_column :bars, :blitz
    remove_column :bars, :things
  end

And if you have the verbose_migrations plugin installed, you can also get some very useful output describing what was done and how long it all took.

Read: Two tips for working with databases in Rails

Topic: Refactoring in Java vs. Ruby Previous Topic   Next Topic Topic: The double inclusion problem

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use