RubyOnRails 2.1 - What's New!

01. 액티브레코드

Tue, 19 Aug 2008 11:04:45 +0900

액티브레코드

액티브레코드(ActiveRecord)는 애플리케이션과 데이터베이스 간의 상호운용성(interoperability)을 담당하는 객체-관계 맵핑 계층이자 데이터 추상화를 담당하기도 한다. (출처: 위키피디어)

sum 메서드

sum 메서드 표현식

이제 예를 들면 sum 같이, 계산을 처리하는 액티브레코드 메서드에서 식(expression)을 사용할 수 있게 되었다.

Person.sum("2 * age")

sum method의 디폴트 반환값 변경

이전 버전에서는, 만약 우리가 액티브레코드의 sum 메서드를 사용하여 테이블의 모든 행의 합을 계산하는데 있어, 메서드 호출 시에 준 조건에 부합하는 행이 아무 것도 없을 경우, 디폴트 반환값은 nil이었다.

레일스 2.1에서는, 디폴트 반환값(즉, 아무 행도 발견되지 않은 경우)은 0이다. 예제를 보자:

Account.sum(:balance, :conditions => '1 = 2') #=> 0

Has_one

through 옵션 지원

has_one 메서드에 through 옵션이 생겼다. 이것은 마치 has_many :through 처럼 동작하지만, 하나의 액티브레코드 객체에 대한 연관을 표현한다는 점이 다르다.

class Magazine < ActiveRecord::Base
has_many :subscriptions
end

class Subscription < ActiveRecord::Base
belongs_to :magazine
belongs_to :user
end

class User < ActiveRecord::Base
has_many :subscriptions
has_one :magazine, :through => : subscriptions,
:conditions => ['subscriptions.active = ?', true]
end

Has_one이 :source_type을 가짐

앞서 언급한 has_one :through 메서드는 또한 :source_type을 취할 수도 있다. 이 부분은 예제를 가지고 설명하겠다. 다음과 같은 두 개의 클래스로 시작하자.

class Client < ActiveRecord::Base
has_many :contact_cards

has_many :contacts, :through => :contact_cards
end

여기 보인 것은 Client 클래스가 여러 종류의 컨택(contacts)을 가지는(has_many) 경우인데, 왜냐면 ContactCard 클래스가 다형적 연관관계(polymorphic relationship)를 갖기 때문이다.

다음 단계로는, ContactCard를 표현하는 두 개의 클래스를 만들자.

class Person < ActiveRecord::Base
has_many :contact_cards, :as => :contact
end

class Business < ActiveRecord::Base
has_many :contact_cards, :as => :contact
end

Person과 Business는 ContactCard 테이블을 통해(through) 내 Client 클래스와 연결된다. 다시 말하면, 나는 두 종류의 컨택, 즉 개인적인 것(personal)과 업무적인 것(business)을 가진다는 말이다.

그렇지만 이건 작동하지 않을 것이다. 내가 컨택을 추출하려하면 어떤 일이 일어나는지 보자.

>> Client.find(:first).contacts
# ArgumentError: /…/active_support/core_ext/hash/keys.rb:48:
# in `assert_valid_keys’: Unknown key(s): polymorphic

이게 작동하게 하려면 :source_type을 사용해야 한다. 이제 Client 클래스를 변경하자.

class Client < ActiveRecord::Base
has_many :people_contacts,
:through => :contact_cards,
:source => :contacts,
:source_type => :person

has_many :business_contacts,
:through => :contact_cards,
:source => :contacts,
:source_type => :business
end

이제 우리는 컨택을 추출하는 두 가지 다른 방법이 생겼다. 어떻게 그럴 수 있는지 유심히 보자. 이제 우리는 어느 컨택의 :source_type을 원하는지 말할 수가 있다.

Client.find(:first).people_contacts
Client.find(:first).business_contacts

Named_scope

has_finder 젬이 named_scope라는 다른 이름으로 레일스에 추가되었다.

이 추가가 레일스에 어떤 것을 가져오는지 완전히 이해하기 위해 다음 예제를 살펴 보자.

class Article < ActiveRecord::Base
named_scope :published, :conditions => {:published => true}
named_scope :containing_the_letter_a, :conditions => "body LIKE '%a%’"
end

Article.published.paginate(:page => 1)
Article.published.containing_the_letter_a.count
Article.containing_the_letter_a.find(:first)
Article.containing_the_letter_a.find(:all, :conditions => {…})

모든 게시된(published) 포스트를 반환하기 위해 published라는 새로운 메서드를 생성하는 대신, 여기서는 이를 위해 named_scope 을 사용하고 있다. 그렇지만 이게 다가 아니다. 어떻게 사용될 수 있는지를 보이는 다른 예제를 하나 보자.

named_scope :written_before, lambda { |time|
{ :conditions => ['written_on < ?', time] }
}

named_scope :anonymous_extension do
def one
1
end
end

named_scope :named_extension, :extend => NamedExtension

named_scope :multiple_extensions,
:extend => [MultipleExtensionTwo, MultipleExtensionOne]

proxy_options로 named_scope 테스팅하기

Named scopes은 레일스 2.1에서 매우 흥미로운 새 기능이지만, 어느 정도 사용하고 난 뒤 보다 복잡한 상황에서의 테스트를 작성하는데 있어 곤란을 겪을 수도 있다.

예제를 하나 보자.

class Shirt < ActiveRecord::Base
named_scope :colored, lambda { |color|
{ :conditions => { :color => color } }
}
end

범위 생성(scope generation)을 검증하는 테스트는 어떻게 작성할까?

이 문제를 해결하고자, proxy_options 메서드가 나왔다. 이 메서드는 named_scope에 사용된 옵션들을 조사할 수 있게 해준다. 만약 위의 코드를 테스트한다면, 다음과 같이 작성할 수 있을 것이다.

class ShirtTest < Test::Unit
def test_colored_scope
red_scope = { :conditions => { :colored => 'red' } }
blue_scope = { :conditions => { :colored => 'blue' } }
assert_equal red_scope, Shirt.colored('red').scope_options
assert_equal blue_scope, Shirt.colored('blue').scope_options
end
end

Increment와 decrement

액티브레코드의 메서드 increment와 increment!, 그리고 decrement와 decrement!는 이제 새로운 옵션 매개변수를 받을 수 있게 되었다. 이전 버전의 레일스에서라면 여러분은 주어진 컬럼에서 1(하나)을 더하거나 빼는 데에 이들 메서드를 사용할 수 있었을 것이다. 레일스 2.1에서는 더하거나 빼는 값을 지정할 수 있다. 다음과 같다.

player1.increment!(:points, 5)
player2.decrement!(:points, 2)

위 예제에서 나는 player1에는 5점을 더하고, player2에서는 2점을 빼고 있다. 이 인수는 선택적이기 때문에, 기존(legacy) 코드는 영향을 받지 않는다.

Find

Conditions

이제부터는, 액티브레코드의 find 메서드에 매개변수로 객체를 넘길 수 있다. 다음 예제를 보자.

class Account < ActiveRecord::Base
composed_of :balance, :class_name => "Money", :mapping => %w(balance amount)
end

이 경우, 우리는 다음과 같이 Account 클래스의 find 메서드 매개변수로 Money의 인스턴스를 전달할 수 있다.

amount = 500
currency = "USD"
Account.find(:all, :conditions => { :balance => Money.new(amount, currency) })

Last

지금까지 우리는 액티브레코드의 find 메서드를 사용하여 데이터를 찾는데 세 개의 연산자만을 사용할 수 있었다. 즉, :first와 :all 그리고 객체의 자체 id가 그것이었다(이 경우는 id 자체를 제외한 어떠한 인수도 전달하지 않는다).

레일스 2.1에서는 네번째 연산자가 생겼으니, 이름하여 :last다. 다음은 몇 가지 예제이다.

Person.find(:last)
Person.find(:last, :conditions => [ "user_name = ?", user_name])
Person.find(:last, :order => "created_on DESC", :offset => 5)

이 새로운 연산자가 어떻게 작동하는건지 완전하게 이해하려면, 다음 테스트만 보면 된다.

def test_find_last
last = Developer.find :last
assert_equal last, Developer.find(:first, :order => 'id desc')
end

All

정적 메서드인 all은 마찬가지로 정적 메서드인 find(:all)의 별칭이다. 예제는 다음과 같다.

Topic.all is the same as Topic.find(:all)

First

정적 메서드인 first은 마찬가지로 정적 메서드인 find(:first)의 별칭이다. 예제는 다음과 같다.

Topic.first is the same as Topic.find(:first)

Last

정적 메서드인 last은 마찬가지로 정적 메서드인 find(:last)의 별칭이다. 예제는 다음과 같다.

Topic.last is the same as Topic.find(:last)

named_scope에서 first와 last 메서드 사용하기

앞서 언급한 모든 메서드들은 named_scope에서도 동작한다. recent라는 named_scope을 만든다고 하자. 다음은 문법적으로 올바른 것이다.

post.comments.recent.last

Eager Loading

이 새로운 기능을 설명하기 위해, 다음 코드를 보자.

Author.find(:all, :include => [:posts, :comments])

여기서 나는 authors 테이블을 검색 중이며, 또한 posts와 comments 테이블도 쿼리 속에 포함하여 검색 중이다. 이 때 쿼리는 author id 컬럼을 통해 이루어지는데, 왜냐면 이게 레일스에서 외래 키 이름 관례상 디폴트 컬럼명이기 때문이다. 이 검색은 다음과 같은 SQL 쿼리를 생성하게 된다.

SELECT
authors."id" AS t0_r0,
authors."created_at" AS t0_r1,
authors."updated_at" AS t0_r2,
posts."id" AS t1_r0,
posts."author_id" AS t1_r1,
posts."created_at" AS t1_r2,
posts."updated_at" AS t1_r3,
comments."id" AS t2_r0,
comments."author_id" AS t2_r1,
comments."created_at" AS t2_r2,
comments."updated_at" AS t2_r3
FROM
authors
LEFT OUTER JOIN posts ON posts.author_id = authors.id
LEFT OUTER JOIN comments ON comments.author_id = authors.id

authors와 posts, 그리고 comments 테이블 간의 조인(joins)을 가지는 정확히 하나의 긴 SQL 쿼리이다. 우리는 이것을 카테시안 곱(cartesian product)이라 부른다.

이런 유형의 쿼리가 언제나 성능면에서 좋은 것은 아니기에, 레일스 2.1에서는 변경되었다. Author에 대한 동일한 쿼리가 이제는 세 개의 테이블에서 정보를 추출하는데 있어 다른 접근법을 사용한다. 레일스는 이제 세 개의 다른 쿼리 - 각 테이블 당 하나씩 -를 사용하며, 이것은 이전에 생성된 쿼리보다 짧은 쿼리들이다. 그 결과는 앞서 보인 레일스 코드를 실행시킨 뒤에 로그 파일을 통해 확인해 볼 수 있다.

SELECT * FROM "authors"
SELECT posts.* FROM "posts" WHERE (posts.author_id IN (1))
SELECT comments.* FROM "comments" WHERE (comments.author_id IN (1))

대부분의 경우 세 개의 보다 간단한 쿼리가 하나의 복잡하고 긴 쿼리보다 빠르게 실행된다.

Belongs_to

belongs_to 메서드는 연관에서 :dependent => :destroy와 :delete를 사용할 수 있게 변경되었다. 다음은 예제다.

belongs_to :author_address
belongs_to :author_address, :dependent => :destroy
belongs_to :author_address_extra, :dependent => :delete,
:class_name => "AuthorAddress"

다형적 URL(Polymorphic url)

액티브레코드를 가지고 작업을 하는 동안에 이름이 변경되는 라우터에 대한 조금 더 근사한 솔루션으로 다형적 URL에 대한 헬퍼 메서드를 사용할 수 있다.

이들 메서드는 연관지을 타입을 지정하지 않은 상태로 RESTful 리소스의 URL을 생성하고자 할 때 유용하다.

사용법은 간단하다. 몇 가지 예제를 보자.(주석으로 처리한 부분은 동일한 것을 레일스 2.1 이전 버전에서 했던 방식이다).

record = Article.find(:first)
polymorphic_url(record) #-> article_url(record)

record = Comment.find(:first)
polymorphic_url(record) #-> comment_url(record)

# 방금 생성한 요소들도 식별할 수 있다
record = Comment.new
polymorphic_url(record) #-> comments_url()

polymorphic_url이 어떻게 주어진 타입을 식별하고서 정확한 라우터를 만들어 내는지를 유심히 보자. 중첩 리소스(nested resources)와 네임스페이스(namespaces)도 지원된다.

polymorphic_url([:admin, @article, @comment])
#-> this will return:
admin_article_comment_url(@article, @comment)

또한 new나 edit, formatted 같은 접두어도 사용할 수 있다. 몇 가지 예제를 보자.

edit_polymorphic_path(@post)
#=> /posts/1/edit

formatted_polymorphic_path([@post, :pdf])
#=> /posts/1.pdf

읽기전용 연관(Readonly relationships)

모델 간 연관관계에도 새로운 기능이 추가되었다. 모델의 상태가 변경되는 것을 막으려면 이제 연관을 기술할 때 :readonly를 사용할 수 있다. 몇 가지 예제를 보자.

has_many :reports, :readonly => true

has_one :boss, :readonly => :true

belongs_to :project, :readonly => true

has_and_belongs_to_many :categories, :readonly => true

이렇게 하면 여러분의 연관 모델은 이 모델 속에서 수정으로부터 자유로울 것이다. 만약 이들 중 무언가를 수정하려고 하면, 여러분은 ActiveRecord::ReadOnlyRecord 예외를 받을 것이다.

add_timestamps와 remove_timestamps 메서드

add_timestamps와 remove_timestamps라는 두 개의 새 메서드가 생겼다. 이 메서드들은 각각 timestamp 컬럼을 추가하고 삭제한다. 예제를 하나 보자.

def self.up
add_timestamps :feeds
add_timestamps :urls
end

def self.down
remove_timestamps :urls
remove_timestamps :feeds
end

Calculations

ActiveRecord::Calculations이 테이블명을 지원하기 위해 조금 변경되었다. 이것은 동일한 컬럼명을 가지는 서로 다른 테이블 간에 연관이 있는 경우 편리하다. 이제 다음 두 가지 옵션이 있다.

authors.categories.maximum(:id)
authors.categories.maximum("categories.id")

ActiveRecord::Base.create accepts blocks

이미 우리는 ActiveRecord::Base.new 에서 블록을 받을 수 있다. 이제 동일한 것을 create 메서드에서도 할 수 있게 되었다.

# 객체를 생성하여 블록으로 넘겨서 그 속성을 기술함.
User.create(:first_name => 'Jamie') do |u|
u.is_admin = false
end

바로 그 메서드는 동시에 여러 객체를 생성하는데도 사용할 수 있다.

# 새로운 객체의 배열을 블록을 사용하여 생성함.
# 블록은 생성된 각 객체에 대해 한번씩 실행됨.
User.create([{:first_name => 'Jamie'}, {:first_name => 'Jeremy'}]) do |u|
u.is_admin = false
end

또한 연관에서도 작동한다.

author.posts.create!(:title => "New on Edge") {|p| p.body = "More cool stuff!"}

# 또는

author.posts.create!(:title => "New on Edge") do |p|
p.body = "More cool stuff!"
end

change_table

레일스 2.0에서 마이그레이션을 생성하는 것은 이전 버전에 비해 많이 섹시해 졌지만, 테이블을 변경하는 부분에서 마이그레이션을 사용하는 것은 전혀 섹시하지 않았다.

레일스 2.1에서는, 새로운 메서드인 change_table을 사용함으로써 테이블을 변경하는 것 역시 섹시해 졌다. 예제를 하나 살펴보자.

change_table :videos do |t|
t.timestamps # 이것은 created_at과 updated_at 컬럼을 생성
t.belongs_to :goat # 이러면 goat_id 컬럼을 추가(integer)
t.string :name, :email, :limit => 20 # 컬럼 name과 email을 추가
t.remove :name, :email # name과 email 컬럼을 제거
end

이 새 메서드 change_table은 그 사촌격인 create_table과 비슷하게 작동하지만, 새로 테이블을 생성하는 대신, 이미 존재하는 테이블에서 컬럼이나 인덱스를 추가 또는 제거하는 방식으로 기존 테이블을 변경한다.

change_table :table do |t|
t.column            # 통상적인 컬럼 추가. 예: t.column(:name, :string)
t.index             # 새 인덱스 추가.
t.timestamps
t.change            # 컬럼 정의를 변경. 예: t.change(:name, :string, :limit => 80)
t.change_default    # 컬럼의 디폴트 값을 변경.
t.rename            # 컬럼명을 변경.
t.references
t.belongs_to
t.string
t.text
t.integer
t.float
t.decimal
t.datetime
t.timestamp
t.time
t.date
t.binary
t.boolean
t.remove
t.remove_references
t.remove_belongs_to
t.remove_index
t.remove_timestamps
end

Dirty Objects

이제 레일스에서 액티브레코드에 생긴 변경을 추적할 수 있게 되었다. 어떤 객체가 변경되었는지 여부를 검사하는 것이 가능해 진 것이다. 만약 변경이 된 경우라면, 최근의 변경을 추적할 수 있다. 몇 가지 예제를 보자.

article = Article.find(:first) article.changed? #=> false
article.title #=> "Title"
article.title = "New Title"
article.title_changed? #=> true

# 변경 전 title을 보여주오
article.title_was #=> "Title"

# 변경되기 전과 변경된 후
article.title_change #=> ["Title", "New Title"]

보다시피 아주 간단하다. 또한 다음 둘 중 하나의 방식으로 모든 변경의 목록을 볼 수도 있다.

# 변경된 모든 속성들의 배열을 반환
article.changed #=> ['title']

# 변경 전후의 값과 함께 변경된 속성들의 해시를 반환
article.changes #=> { 'title’ => ["Title", "New Title"] }

어떤 객체가 저장되면, 그 상태가 변경됨에 유의하자.

article.changed? #=> true
article.save #=> true
article.changed? #=> false

만약 attr=을 사용하지 않고 객체의 상태를 변경하려는 경우라면, 속성이 변경되었다는 사실을 명시적으로 알려야 하며, 이 때 사용하는 메서드가 attr_name_will_change!이다(attr 를 객체의 실제 속성으로 대체할 것). 마지막 하나의 예제를 보자.

article = Article.find(:first)
article.title_will_change!
article.title.upcase!
article.title_change #=> ['Title', 'TITLE']

부분 갱신(Partial Updates)

Dirty Objects를 구현하는 것은 다른 아주 흥미로운 기능들의 시작점이 된다.

이제 우리는 객체의 변경된 상태가 어떤지를 추적할 수 있게 되었다. 그렇다면 데이터베이스에 불필요한 업데이트를 피하지 못할 이유가 어디 있을까?

이전 버전의 레일스에서는 이미 존재하는 액티브레코드 객체에 대해 save 메서드를 호출하면, 그 객체의 모든 필드들이 데이터베이스에 업데이트되었다. 심지어는 아무런 변경도 하지 않은 경우도 마찬가지였다.

이 작업은 Dirty Objects을 사용하는 것으로 상당부분 개선될 수 있었고, 그게 바로 지금 일어난 일이다. 레일스 2.1이 생성한 SQL 쿼리를 하나 살펴보자. 부분적인 변경을 가한 객체를 저장하는 것이다.

article = Article.find(:first)
article.title #=> "Title"
article.subject #=> "Edge Rails"

# title을 변경하자
article.title = "New Title"

# 다음과 같은 SQL을 생성한다
article.save
#=> "UPDATE articles SET title = 'New Title' WHERE id = 1"

애플리케이션에서 변경된 필드만이 데이터베이스에 업데이트됨에 유의하자. 만약 애플리케이션에서 아무런 필드도 업데이트되지 않았다면, 액티브레코드는 아무런 업데이트도 수행하지 않을 것이다.

이 새 기능을 활성/비활성 시키려면, 모델과 연관된 partial_updates 속성을 변경하면 된다.

# 활성화시키기
MyClass.partial_updates = true

만약 모든 모델에 대해 이 기능을 활성/비활성 시키고자 한다면, config/initializers/new_rails_defaults.rb 파일을 수정해야 한다.

# 모든 모델에서 기능 활성화시키기
ActiveRecord::Base.partial_updates = true

만약 attr=메서드를 사용하지 않고 필드를 수정할 요량이라면, 이것 역시 config/initializers/new_rails_defaults.rb를 통해 레일스에 알려야 함을 잊지 말자.

# 만약 여러분이 **attr=**를 사용한다면,
# 알리지 않아도 좋아요
person.name = 'bobby'
person.name_change # => ['bob', 'bobby']

# 그렇지만 **attr=**를 사용할 게 아니라면
# 필드가 변경될 거란 사실을 꼭 알려 주세요
person.name_will_change!
person.name << 'by'
person.name_change # => ['bob', 'bobby']

만약 이런 식으로 변경을 알리지 않으면, 추적이 이루어지지 않을 것이고, 따라서 데이터베이스 테이블은 제대로 업데이트되지 않을 것이다.

MySQL에서 Smallint, int 또는 bigint?

액티브레코드 MySQL 어댑터는 이제 데이터베이스의 컬럼을 생성하거나 변경할 때 조금 더 영리해져서 integer 타입을 사용할 수 있게 되었다. :limit 옵션을 통해 이제 컬럼이 smallint인지 int인지 또는 bigint인지를 알릴 것이다. 다음은 그게 어떻게 작동하는지를 보이는 예제다.

case limit
when 0..3
"smallint(#{limit})"
when 4..8
"int(#{limit})"
when 9..20
"bigint(#{limit})"
else
'int(11)'
end

이제 이것은 migration 파일에 적용하여 각 컬럼에 대해 어떤 컬럼 타입이 만들어 지는지 알아 보자.

create_table :table_name, :force => true do |t|

# 0 - 3: smallint
t.integer :column_one, :limit => 2 # smallint(2)

# 4 - 8: int
t.integer :column_two, :limit => 6 # int(6)

# 9 - 20: bigint
t.integer :column_three, :limit => 15 # bigint(15)

# if :limit is not informed: int(11)
t.integer :column_four # int(11)
end

PostgreSQL 어댑터에는 이 기능이 이미 들어가 있으며 이제 MySQL에서도 따라 왔다.

has_one과 belongs_to에서의 :select 옵션

이미 알려진 메서드인 has_one과 belongs_to에 새로운 옵션:select가 들어 왔다.

이 옵션의 디폴트 값은 "*"이지만("SELECT * FROM table"에서와 같이), 여러분은 사용하려고 하는 컬럼만 추출하도록 그 값을 편집할 수가 있다..

이 때 주(primary) 키와 외래 키(foreign keys)를 포함시키는걸 잊어서는 안된다. 그러지 않으면 오류가 나올 것이다.

belongs_to 메서드는 더 이상 :order 옵션을 가지지 않는다. 그렇다고 걱정할 건 없다. 그걸 사용하는 경우는 없었으니 말이다.

STI를 사용할 때 클래스의 완전한 이름 저장하기

네임스페이스(namespace) 및 STI와 함께 모델을 사용할 때, 액티브레코드는 단지 클래스명만을 저장하며, 그 네임스페이스는 저장하지 않는다(모듈이 풀어진다demodulized). 이렇게 되면 STI 상에 있는 모든 클래스가 동일한 네임스페이스에 있는 경우에만 작동하게 된다. 예제를 보자.

class CollectionItem < ActiveRecord::Base; end
class ComicCollection::Item < CollectionItem; end

item = ComicCollection::Item.new
item.type # => 'Item’

item2 = CollectionItem.find(item.id)
# 오류가 나온다. 왜냐면 Item 클래스를 찾을 수 없기 때문이다.

이번 변경에서는 액티브레코드가 클래스의 전체 이름을 저장하도록 해주는 새로운 옵션이 하나 추가되었다.

이 기능을 활성/비활성 시키려면, 다음을 environment.rb에 포함시키거나 또는 편집해야 한다.

ActiveRecord::Base.store_full_sti_class = true

Its default value is true.

table_exists? 메서드

AbstractAdapter 클래스에 table_exists?라는 새 메서드가 추가되었다. 사용법은 간단하다.

>> ActiveRecord::Base.connection.table_exists?("users")
=> true

타임스탬프 기반 마이그레이션

이제 막 레일스를 시작하거나 또는 여러분만의 무언가를 개발하려 할 때, 마이그레이션은 여러분의 모든 문제를 해결해 주는 최상의 솔루션같아 보인다. 그러나 개발자들과 팀을 이루는 프로젝트에서는, 마이그레이션에서 생기는 레이스 조건(race condition)을 다루는 것이 꽤나 골칫거리가 된다는 걸 알게 될 것이다(아직은 아닐 수도 있지만). 이런 경우는 레일스 2.1에 새로 도입된 타임스탬프 기반 마이그레이션이 구원투수다.

타임스탬프 기반 마이그레이션(timestamped migrations)이 도입되기 전에는, 각각의 새로 생성된 마이그레이션에는 마이그레이션명 앞에 숫자가 따라 붙었다. 만약 두 개의 마이그레이션이 서로 다른 개발자에 의해 만들어져서 그 즉시 커밋되지 않은 경우라면, 똑같은 마이그레이션 번호에 서로 다른 정보를 담고 있는 마이그레이션이 만들어 질 수 있었다. 이 때 여러분의 schema_info는 구닥다리(out of date)가 되고 소스 컨트롤 상에는 충돌이 생긴다.

이 문제를 해결하기 위해 많은 "시도"들이 있었다. 여러 가지 플러그인들이 각기 다른 접근법으로 이 문제를 해결하기 위해 만들어 졌다. 사용할 수 있는 플러그인들에도 불구하고, 한가지는 분명해 졌다. 즉, 옛날 방식은 한마디로 작동하지 않았다는 것이다.

만약 여러분이 Git을 사용하고 있다면, 더 깊은 수렁에 빠지게 될 것인데, 왜냐면 여러분 팀에는 아마도 두 개 이상의 작업 브렌치(working branch)가 존재하고 그들 모두에 구닥다리 마이그레이션이 있을 것이기 때문이다. 아마도 브렌치를 병합할 때에 심각한 충돌 문제에 직면하게 될 것이다.

이 커다란 문제를 해결하기 위해 코어팀은 레일스의 마이그레이션 작동 방법을 변경하였다. schema_info의 버전 카운트에 대응하는 번호를 각 마이그레이션 파일의 앞에 붙이는 대신, UTC 시간에 기반하면서 YYYYMMDDHHMMSS 형식을 따르는 문자열을 앞에 붙이기로 한 것이다.

이와 함께 schema_migrations라고 하는 새로운 테이블도 만들어져서 이미 실행된 마이그레이션들이 무언지에 관한 정보를 담게 된다. 이런 식으로 하여, 만약 누군가가 조금 더 적은 번호의 마이그레이션을 생성하면, 레일스는 그 이전 버전까지 로 롤백(rollback)하게 되고 이어서 현재 버전에 이르기까지의 모든 것들을 실행할 것이다.

명백히, 이 방식은 마이그레이션과 관련된 충돌 문제를 해결한다.

이 기능을 비활성화 시키려면 environment.rb에 다음 줄을 포함시키면 된다.

config.active_record.timestamped_migrations = false

또한 마이그레이션을 "헤집고 다니는" 새 레이크 태스크도 생겼다.

rake db:migrate:up
rake db:migrate:down

05. 액션컨트롤러

Fri, 04 Jul 2008 18:32:49 +0900

액션컨트롤러

액션 컨트롤러는 웹으로부터 요청을 받아 특정 작업 수행하고, 그 결과로 무언가를 렌더링 할 것인지, 혹은 다른 액션으로 리다이렉트 할 것인지 등을 결정하는 책임을 가진 레이어다.

액션은 컨트롤러 안에서 퍼블릭 메서드로 정의되며, 이 메서드는 라우팅에 의해 자동으로 실행된다.

ActionController::Routing

Map.root

지금부터는 map.root를 정의할 때, 여기에 별칭(alias)을 사용해 중복을 피할 수 있다(DRY).

레일스의 이전 버전에서는 다음과 같이 사용했었다:

map.new_session :controller => 'sessions', :action => 'new'
map.root :controller => 'sessions', :action => 'new'

이제는 다음과 같이 할 수 있다:

map.new_session :controller => 'sessions', :action => 'new'
map.root :new_session

라우트 인식

라우트 인식(Routes recognition)을 구현하는데 예전에는 라우트 하나하나를 모두 검사했었는데, 이 방식은 간혹 긴 응답시간을 보이기도 했다. 그래서 새로운 방식의 더 똑똑한 구현이 도입되었다. 이제 라우트의 트리를 생성하고, 라우트 인식은 유사한 라우트를 접두어로 묶고, 건너뛰기도 한다. 이 방식은 시간을 대략 2.7배 정도 단축시켰다.

모든 구현은 recognition_optimisation.rb 파일에 있으며, 실제 동작에 대한 자세한 사항은 주석으로 잘 설명하고 있다. 이 구현에 대하여 더 많은 정보를 얻고자 한다면 소스코드 안에 있는 문서를 참고하길 바란다.

Assert_routing

이제 라우트를 테스트할 때 HTTP 메서드를 함께 사용할 수 있다. 아래 예제를 보라:

assert_routing({ :method => 'put',
:path => '/product/321' },
{ :controller => "product",
:action => "update",
:id => "321" })

Map.resources

영어가 아닌 언어를 사용하는 사이트가 있고, 이 사이트에서 라우트를 그 언어로 정의하고 싶다고 가정해보자. 예를 들어 아래 URL이 있다.

http://www.mysite.com.br/products/1234/reviews

이 URL 대신 다음과 같이 하기를 원한다고 해보자.

http://www.mysite.com.br/produtos/1234/comentarios

이것은 이미 가능하긴 하지만, 쉬운 방법이 아니며 레일스 관례에 반하는 것이기도 하다.

지금부터는 라우트에 개인화를 적용하기 위한 용도로 map.resources에 :as 옵션을 사용할 수 있다. 아래는 위 URL을 포트투갈어로 바꾸는 예제다.

map.resources :products, :as => 'produtos' do |product|
# product_reviews_path(product) ==
# '/produtos/1234/comentarios’
product.resources :product_reviews, :as => 'comentarios'
end

ActionController::Caching::Sweeping

레일스의 이전 버전에서 sweeper를 선언할 때는, 클래스를 심볼을 사용하여 표현했다:

class ListsController < ApplicationController
caches_action :index, :show, :public, :feed
cache_sweeper :list_sweeper, :only => [ :edit, :destroy, :share ]
end

이제 심볼 대신 클래스를 직접 사용해 선언할 수 있게 되었다.

이는 sweeper가 모듈 안에 정의되어 있는 경우 필요하다. 물론 여전히 심볼를 사용할 수도 있지만, 아래처럼 하는 것도 가능하다.

class ListsController < ApplicationController
caches_action :index, :show, :public, :feed
cache_sweeper OpenBar::Sweeper, :only => [ :edit, :destroy, :share ]
end

07. Railties

Tue, 01 Jul 2008 16:12:08 +0900

Railties

config.gem

environment.rb 파일에 있는 config.gem 설정을 이용해서 프로젝트를 실행하는데 필요한 모든 gem들을 설정할 수 있다. 이 설정은 프로젝트가 사용하는 gem들에 대한 의존관계를 명시한다.

config.gem "bj"

config.gem "hpricot", :version => '0.6',
:source => "http://code.whytheluckystiff.net"

config.gem "aws-s3", :lib => "aws/s3"

의존관계에 있는 gem들을 모두 설치하고 싶으면 다음과 같은 Rake 태스크를 이용할 수 있다.

# Installs all specified gems
rake gems:install

어떤 gem들이 프로젝트에서 사용되고 있는지 보기 위해서 다음과 같은 Rake 태스크를 이용할 수 있다.

# Listing all gem dependencies
rake gems

gem 이 rails/init.rb 파일을 가지고 있는 상태에서, 애플리케이션이 gem을 포함하기를 원한다면 다음 Rake 태스크를 이용할 수 있다.

# Copy the specified gem to vendor/gems/nome_do_gem-x.x.x
rake gems:unpack GEM=gem_name

그러면 gem_name의 gem은 vendor/gems/gem_name-xxx 디렉토리에 복사될 것이다. gem_name 을 사용하지 않는 경우에는 vendor/gem 디렉토리에 모든 gem들을 복사할 것이다.

플러그인에서의 config.gem

config.gem 설정은 플러그인에서도 역시 사용 가능하다.

Rails 2.0 까지는 플러그인의 init.rb 파일이 다음과 같은 형식이었다.

# init.rb of plugin open_id_authentication
require 'yadis'
require 'openid'
ActionController::Base.send :include, OpenIdAuthentication

그러나, Rails 2.1 에서는 init.rb 파일이 다음과 같을 것이다.

config.gem "ruby-openid", :lib => "openid", :version => "1.1.4"
config.gem "ruby-yadis", :lib => "yadis", :version => "0.3.4"

config.after_initialize do
ActionController::Base.send :include, OpenIdAuthentication
end

모든 필요한 gem들을 설치하는 태스크(rake gems:install)를 수행할 때, 이 gem들 역시 설치될 것이다.

gems:build

gems:build 태스크는 gems:unpack을 통해 설치된 gem들의 native extension들을 컴파일 한다. 문법은 다음과 같다.

rake gems:build # 모든 gem들에 대해
rake gems:build GEM=mygem # mygem에 대해서만

서버를 시작할때 보여지는 새 메시지

Rails 서버를 시작할 때 약간의 개선사항이 있다. 그것은 실핻되는 Rails의 버전을 보여주는 것이다.

Rails 2.1 application starting on http://0.0.0.0:3000

Rails.public_path

Rails.public_path 를 통해 프로젝트의 "public" 디렉토리를 알 수 있다.

Rails.public_path

Rails.logger, Rails.root, Rails.env and Rails.cache

Rails 2.1에서는 RAILS_DEFAULT_LOGGER, RAILS_ROOT, RAILS_ENV, 그리고 RAILS_CACHE 상수들 대신 다음과 같이 사용할 수 있다.

# RAILS_DEFAULT_LOGGER
Rails.logger

# RAILS_ROOT
Rails.root

# RAILS_ENV
Rails.env

# RAILS_CACHE
Rails.cache

Rails.version

Rails 2.0 까지는 실행 중에 어떤 Rails 버전이 사용되고 있는지 확인하기 위해 다음과 같은 코드가 사용되었다.

Rails::VERSION::STRING

Rails 2.1에서는 다음과 같이 더 간편해졌다.

Rails.version

플러그인에 대한 정보 얻기

이것은 Rails 2.0의 새로운 기능 중 하나이다. 아마 잘 사용하지는 않았겠지만.. 하지만 이것은 플러그인의 버젼을 알고 싶은 경우 같은 특수한 상황에서는 유용할 수 있다.

테스트을 위해 다음과 같이 plugin 디렉토리에 about.yml이라는 새 파일을 생성한다.

author: Carlos Brando
version: 1.2.0
description: A description about the plugin
url: http://www.nomedojogo.com

이 정보를 다음과 같은 코드로 얻을 수 있다.

plugin = Rails::Plugin.new(plugin_directory)
plugin.about["author"] # => “Carlos Brando”
plugin.about["url"] # => “http://www.nomedojogo.com”

이 기능에 대해 유용한 사용방법을 알고 있고, 그것을 공유하고 싶으면 알려주세요.

08. 래이크 작업

Tue, 01 Jul 2008 16:07:58 +0900

Rake Tasks, 플러그인, 그리고 Scripts

Rake Tasks

rails:update

이제부터 rake rails:freeze:edge 태스크를 수행할 때마다 rails:update 태스크도 수행된다. 그럼으로써 config 파일들과 JavaScripts 를 갱신한다.

127.0.0.1에 있는 database

database.rake는 local database에 대해 localhsot 만 인식했다. 이제는 127.0.0.1 역시 인식한다. 이것은 create와 drop 태스크 모두에 동작한다. 또한 database.rake 파일은 중복을 줄이기 위해 리팩토링되었다.

특정한 Rails의 릴리즈를 얼리기(Freezing).

Rails 2.1 이전에는 특정한 Rails의 릴리즈를 프로젝트에 얼리기가 불가능했다. 다만 Revision을 파라미터로 사용할 수 있었을 뿐이었다. Rails 2.1 에서는 아래와 같이 특정한 릴리즈를 선택해서 얼릴 수 있다.

rake rails:freeze:edge RELEASE=1.2.0

시간대(TimeZone)

rake time:zones:all

Rails가 알고 있는 모든 시간대(time zone)들을 오프셋(offset)으로 그룹지어 보여준다. OFFSET 옵션 파라미터를 이용해서 결과를 걸러낼 수 있다.

예를 들면 OFFSET=-6 는 오프셋이 -6:00인 시간대만 보여준다.

rake time:zones:us

US 시간대의 목록을 보여준다. OFFSET 옵션을 사용할 수 있다.

rake time:zones:local

당신의 OS의 시간대 오프셋과 같은 시간대 목록을 보여준다.

Scripts

plugin

script/plugin install 명령에 -e/--export 옵션을 사용할 수 있다. 이 옵션이 설정되어 있으면 svn export를 수행한다.

그리고 GIT 저장소(repository)에 있는 플러그인들에 대한 지원이 추가되었다.

dbconsole

이 스크립트는 database에 대해 script/console과 같은 동작을 한다. 즉 database의 명령 수행 클라이언트(command line client)에 접속한다.

코드를 살펴보면, 이 스크립트는 mysql, postgresql 그리고 sqlite(3) 에서만 동작할 것임을 알 수 있다. 다른 database가 database.yml에 설정되어 있다면, 이 스크립트는 "not supported for this database type" 메시지를 보여줄 것이다.

Plugins

Gem 도 플러그인이다.

이제, rails/init.rb 를 가지고 있는 모든 gem들은 플러그인처럼 Rails 프로젝트의 vendor 디렉토리 밑에 설치될 수 있다.

플러그인에서 generators 사용하기기

Rails가 vendor/plugin 디렉토리가 아닌 다른 곳에서 플러그인을 찾도록 할 수 있다. environment.rb에 다음과 같은 형식의 코드를 추가하기만 하면 됩다.

config.plugin_paths = ['lib/plugins', 'vendor/plugins']

Rails 2.0에서는 위와 같은 설정애서 플러그인이 generators를 가질 때 나타나는 버그가 있었다. 이 버그 때문에 Rails는 vendor/plugins 디렉토리 안에 있는 plugin에서만 generators를 찾았다. 2.1에서는 이 버그가 해결됬다.

12. 수정된 버그

Tue, 24 Jun 2008 21:31:25 +0900

수정된 버그

PostgreSQL에서 컬럼추가

PostgreSQL 데이터베이스를 쓰면서, 마이그레이션에서 기존 테이블에 컬럼을 추가할 때 버그가 있다. 예제를 보자.

File: db/migrate/002_add_cost.rb

class AddCost < ActiveRecord::Migration
def self.up
add_column :items, :cost, :decimal, :precision => 6, :scale => 2
end

def self.down
remove_column :items, :cost
end
end

:precision => 6, :scale => 2 옵션을 주고 컬럼을 생성할 것이다.. rake db:migrate 를 실행한다. 변경된 테이블 내역을 확인해보겠다.

Column	Type	Modifiers
id	integer	not null
desc	character varying(255)
price	numeric(5,2)
cost	numeric

"cost"컬럼이 생성되었지만 numeric타입이다. "price"와 같은 컬럼타입이라 추측할 수도 있다. 하지만 정확하게 numeric(6,2) 타입이 되어야만 한다. 이 버그는 레일스2.1에서 해결되었다. 이제 컬럼은 의도한 대로 생성될 것이다.

마임타입(Mime Types)

request.format 속성값으로서 심벌(symbol)을 쓸 수 없었던 버그이다. 버그는 수정되었고 아래와 같이 쓸 수 있다.

request.format = :iphone
assert_equal :iphone, request.format

change_column시에 버그수정

:null=>false옵션으로 생성된 컬럼을 :null=>true인자를 주고 change_column했을 때 적용되지 않던 버그가 수정되었다.

98. 번역 현황 테이블

Tue, 24 Jun 2008 21:29:26 +0900

Chapter별 번역 현황 테이블

Chapter	번역 상태	번역자
00. 소개	완료	deepblue
01. 액티브레코드	완료	thinkr
02. 액티브서포트		deepblue
03. 액티브리소스	완료	deepblue
04. 액션팩	완료	jasonpa
05. 액션컨트롤러	완료	humbroll
06. 액션뷰	완료	ikspres
07. Railties	완료	chang
08. 래이크 작업	완료	chang
09. Prototype과 script.aculo.us	완료	deepblue
10. 루비 1.9	완료	deepblue
11. 디버그	완료	deepblue
12. 수정된 버그	완료	allieus
13. 추가 정보	완료	jangxyz

99. 번역 진행 상황판

Tue, 24 Jun 2008 21:28:39 +0900

이 페이지는 위로 자랍니다.

12. 수정된 버그 마쳤습니다. - allieus
04. 액션팩 마쳤슈 - jasonpa
13. 추가 정보 번역 마쳤습니다. - jangxyz
13. 추가 정보 번역 시작합니다. - jangxyz
4장 13장도 부탁드립니다. 어서 찜 해주세요. - deepblue
02. 액티브서포트 번역 시작합니다 - deepblue
01. 액티브레코드 번역 마쳤습니다. - thinkr
07. Railties 번역 마쳤습니다. - chang
07. Railties 번역 시작합니다. - chang
01. 액티브레코드 번역 시작합니다. - thinkr
08. 래이크 작업 번역 마쳤습니다. - chang
06. 액션뷰 번역 마쳤습니다. - ikspres
06. 액션뷰 번역 시작합니다. - ikspres
08. 래이크 작업 번역 시작합니다. - chang
05. 액션컨트롤러 시작합니다. - humbroll
- 오호 humbroll 안녕~~ - deepblue
  - 다 했는데 어색한 부분이 약간 있어요.ㅋ 봐주세요~ - humbroll
  - 05. 액션컨트롤러 마쳤습니다.- humbroll
    - 수고하셨습니다. 제가 조금 수정해보았습니다 - deepblue
짧은 챕터 하나 ( 12. 수정된 버그 ) 시작합니다 - allieus
- allieus님 환영해요 ^^ - deepblue
- 번역이 어눌합니다. 느리지만 천천히 번역해보도록 하겠습니다. 감사합니다. :) - allieus
  - 다같이 힘을 모으면, 잘 될꺼예요~ 화이팅! - deepblue
짧은 챕터들(9, 10,11) 마쳤습니다 - deepblue
03. 액티브리소스 번역 마쳤습니다 - deepblue
03. 액티브리소스 번역합니다. - deepblue
00. 소개 번역 마쳤습니다 - deepblue
00.소개 번역합니다. - deepblue