Posted by ryan
at 7:04 PM
on Tuesday, May 29, 2007
Not two days after I just implemented these tasks myself for a client project comes the addition of some useful rake tasks that handle the provisioning of your database.
Want to create your database without having to drop into that pesky mysql command prompt? Then I believe rake db:create is your man. Don’t need that database anymore? Give rake db:drop a try. Want to tear down your database and re-create it, migrations and all? rake db:reset is your jack-of-all-trades then.
And all the options you’re used to when raking the database still apply:
1
2
3
4
5
|
# Drop the test database
RAILS_ENV=test rake db:drop
# Recreate the staging database, but only migrate it to version 3
RAILS_ENV=staging rake db:reset VERSION=3 |
If you haven’t made rake a part of your life yet, it’s time you do so.
tags: ruby,
rubyonrails
Posted by ryan
at 6:54 PM
on Tuesday, May 29, 2007
validates_numericality_of just got a shot of mojo this weekend in the form of some highly useful options.
Prior to this recent change, your numerical validation options were limited to
only_integer and
allow_nil. Any desires to do anything slightly more complex meant dropping down into your own validation routine. Now, some of the more common validations one might want on a number parameter have been option-ized, including:
greater_than
greater_than_or_equal_to
equal_to
less_than
less_than_or_equal_to
odd
even
Which allows us to do things such as:
1
2
3
4
|
validates_numericality_of :salary, :greater_than_or_equal_to => 40000
validates_numericality_of :ten, :equal_to => 10
validates_numericality_of :bonus, :less_than => 5000
validates_numericality_of :prime, :odd => true |
So put away that crusty custom validate and plug into these fresh validation options. Guaranteed to make your life easier.
tags: ruby,
rubyonrails
Posted by ryan
at 11:17 AM
on Wednesday, May 23, 2007
For all of you that were swamped with stuff prepping for RailsConf, it’s time to shift your focus to the 2007 Ruby Hoedown. Did you present at RailsConf and think it might be appropriate for a Ruby (not Rails) conference? If so, submit your proposal to us by June 2nd and we’ll take a look. Did RailsConf get your intellectual juices flowing? What better way to flex that new intellectual muscle than with a presentation at the Hoedown? You’ve got about a week left to make it happen!
Really want to set the mood? Then have a listen to our 2007 Ruby Hoedown Ad. (not my voice, by the way)
rubyonrails, rubyhoedown, railsconf2007
Posted by ryan
at 8:48 AM
on Monday, May 07, 2007
ActiveResource find Updates
The ActiveResource find method just got a little bit of tightening with a new :from option. This option basically replaces the ability to call a custom method with a single argument to find and makes find a little less open-ended.
For instance, if before you were invoking a recent custom method:
|
Post.find(:recent) #=> GET /posts/recent.xml |
you will now need to declare the multiplicity or scope (:all in this case) as the first argument and the custom method as the :from option:
|
Post.find(:all, :from => :recent) #=> GET /posts/recent.xml |
You can also do the same for singleton resources with the :one scope:
|
Post.find(:one, :from => :latest) #=> GET /post/latest.xml |
And if you just want to manually specify the location from which to get the post, you can use the actual string URI:
|
Post.find(:one, :from => "/categories/1/latest.xml") #=> GET /categories/1/latest.xml |
So basically what’s happened is that the first argument to find has been tightened to allow either the resource id or the scope (:all, :first, :one) and any custom method or manual resource location has been moved to the :from option.
ActiveResource Custom Headers
ActiveResource was also recently updated to include the ability to set custom headers per resource.
1
2
3
|
class Post < ActiveResource::Base
headers['X-MyHeader'] = 'ryan'
end |
Every request from Post will now include that header.
Note: The original patch used custom_headers but was since changed to headers
It’s refreshing to see ActiveResource getting better and easier to use!
tags: ruby, rubyonrails, REST
Posted by ryan
at 6:08 PM
on Sunday, May 06, 2007
has_many and has_one RESTful Routing
Until the day comes that Rails’ routing can interrogate your domain model and properly translate the existing ActiveRecord associations into RESTful routes, we will have to settle for the same sugary-sweet declaration syntax. Instead of nesting resources in your routing configuration to imply an association, you can now directly specify the routing association with has_one and has_many:
|
map.resources :posts, :has_one => :author, :has_many => [:comments, :trackbacks] |
This gets you what you’re used to seeing as:
1
2
3
4
5
|
map.resources :posts do |posts|
posts.resource :author
posts.resources :comments
posts.resources :trackbacks
end |
You can always drop back to the nested form to specify more detailed options, but for vanilla routes this gets you an intuitive way to specify resource relationships that are directly reflected in your routing.
Auto Routing Name Prefixing
As part of the same update you no longer have to specify a named prefix for nested resources (to avoid conflicts with other named routes) – now named prefixes are assumed for you based on the resource nesting. For instance, this routing:
1
2
3
|
map.resources :posts do |posts|
posts.resources :comments
end |
now provides a post_comments_url(post_id) helper method. Previously, you had to specify the post_ part of the name via the name_prefix option for your route:
1
2
3
|
map.resources :posts do |posts|
posts.resources :comments, :name_prefix => "post_"
end |
Now that prefix is assumed for you (an assumption that could potentially break your routing and helper methods). If you don’t want the name_prefix assumed, you’ll need to explicitly set it to nil with :name_prefix => nil.
And don’t forget about the routing namespace update too
tags: ruby, rubyonrails
Posted by ryan
at 5:36 PM
on Sunday, May 06, 2007
You know those sexy migrations you’ve been lusting over? Yeah, well they’re mainstream now. I won’t unnecessarily duplicate here what’s already been written about them – but the gist is that a sexy migrations inspired syntax is now part of Rails.
You can now do:
1
2
3
4
5
|
create_table "users", :force => true do |t|
t.integer :group_id, :employer_id
t.string :first, :last
t.timestamps
end |
To get integer columns in group_id and employer_id and string columns in first and last. timestamps gets you the magic columns created_at and updated_at.
The list of supported column types are:
string
text
integer
float
decimal
datetime
timestamp
time
date
binary
boolean
So spin that Barry White record and lay it down right, sexy’s back.
tags: ruby, rubyonrails