Two tips for working with databases in Rails
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.
Reader Comments
14 Dec 2005
14 Dec 2005
14 Dec 2005
14 Dec 2005
14 Dec 2005
1 Mar 2006