Nome do Jogo

Outro recurso que também foi muito solicitado e estará disponível com a versão 2.3 do Rails é uma melhoria nas nested transactions (transações aninhadas).

Atualmente no Rails já podemos aninhar transações, ou em um português mais simples podemos colocar uma transação dentro de outra. Veja um exemplo:

User.transaction do
  User.create(:username => 'Kotori')
  User.transaction do
    User.create(:username => 'Nemu')
    raise ActiveRecord::Rollback
  end
end

User.find(:all) # => empty

Resumindo o exemplo acima: Criei uma transação e inclui um novo usuário no banco, então criei uma segunda transação dentro da primeira e inclui um segundo usuário, e no fim disparei uma exceção que faz com que a primeira transação e todas as suas filhas sejam desfeitas como você pode ver no resultado do método find.

A novidade é a opção :requires_new. Quando usada em uma sub-transação, caso alguma coisa dê errado somente as alterações feitas dai em diante é que serão desfeitas. Veja um novo exemplo, agora com este recurso habilitado:

User.transaction do
  User.create(:username => 'Kotori')
  User.transaction(:requires_new => true) do
    User.create(:username => 'Nemu')
    raise ActiveRecord::Rollback
  end
end

User.find(:all) # => Returns only Kotori

Como você pode ver no retorno do método find, ao realizar o rollback somente a inclusão do segundo usuário foi desfeita, já que estou usando a opção :requires_new habilitada na segunda transação.

Nem todo banco de dados tem suporte real a nested transactions. Na verdade, até o momento somente o MS-SQL tem esta funcionalidade. Mas não se preocupe se você estiver usando outro banco de dados, o Active Record consegue emular nested transactions usando savepoints.

ATENÇÃO: Caso você esteja usando o MySQL, então não faça operações DDL em nested transactions que estiverem emulando savepoints. Ou seja, não tente executar algo como ‘CREATE TABLE’ nestes blocos. Isto acontece porque o MySQL automaticamente libera todos os savepoints após executar uma operação DDL. Então quando a transação terminar e tentar liberar os savepoints criados, ocorrerá um erro no banco já que todos os savepoints foram liberados antes da hora. Para entender melhor, veja o exemplo abaixo:

# INICIO
Model.connection.transaction do
  # CRIA O SAVEPOINT active_record_1
  Model.connection.transaction(:requires_new => true) do
    # active_record_1 é automaticamente liberado
    Model.connection.create_table(...)
  end # LIBERA o savepoint active_record_1

  # ^^^^ BOOM! database error!
end

Apesar deste pequeno detalhe, em todos os outros casos este recurso tem funcionado perfeitamente.

Finders dinâmicos não são mais novidades no Ruby on Rails há muito tempo, qualquer um que já tenha trabalhado em um simples projeto Rails, já fez algo assim:

User.find_by_first_name_and_age('Pedro', 20)

Sabemos que o método acima não existe, mas graças aos finders dinâmicos podemos usá-lo para recuperar todos os usuários que tenham como primeiro nome ‘Pedro’ e 20 anos de idade.

Outro recurso, um pouco mais novo, que também tem se mostrado muito útil são os named scopes. Com este recurso podemos definir um escopo como base para uma pesquisa. Por exemplo:

class Article < ActiveRecord::Base
  named_scope :published, :conditions => { :published => true }
end

Article.published.all :limit => 5

No exemplo acima estou usando o escopo published que ajustará minha pesquisa para que apenas artigos publicados sejam devolvidos, mas acrescentando o método all também posso limitar a quantidade de artigos retornados em cinco. Este tipo de flexibilidade não é possível em finders dinâmicos.

Para resolver esta deficiência foi adicionado um novo recurso ao Rails chamado dynamic scopes (escopos dinâmicos). Imagine esta funcionalidade como uma mistura dos dois conceitos que acabamos de ver.

Agora você poderá criar escopos de forma dinâmica, da mesma forma como já fazíamos através do find_by. Desta forma:

User.scoped_by_first_name_and_age 'Pedro', 20

Mas com a vantagem de poder usar toda a flexibilidade de um escopo:

User.scoped_by_first_name_and_age('Pedro', 20).all(:limit => 5)

Da mesma forma como fazíamos em escopos comuns, também podemos preceder um escopo com outro escopo:

User.scoped_by_first_name('Pedro').scoped_by_age(20)

Enfim, mais um grande ganho à nossa produtividade.

Finalmente a série de artigos cobrindo todas as novas funcionalidades do Rails 2.2 terminou, e de agora em diante somente novas adições serão cobertas. Não sabemos ao certo se a próxima versão do Rails será a 2.3 ou 3.0, mas aqui chamaremos apenas de Edge Rails.

Outra novidade neste blog foi a adição do Google Connect. Vocês podem encontrar na primeira página uma caixa para se cadastrar no menu lateral. Ainda não inclui todas funcionalidades, até o momento é possível apenas se associar ao blog, mas futuramente serão permitidos comentários via esta ferramenta, além de outros tipos de colaboração. A idéia no momento é apenas testar ferramenta.

Vamos ao que realmente interessa. No Rails 2.1 tivemos a introdução dos named_scope, que se tornaram ferramentas poderosas em nossas mãos. Mas na próxima versão do Rails teremos também um default_scope.

Ele funciona exatamente como um named_scope, mas como o próprio nome diz é um escopo padrão que deve ser usado em todas as pesquisas. Vejamos alguns exemplos:

class Person < ActiveRecord::Base
  default_scope :order => 'last_name, first_name'
end

No exemplo acima estou definindo o escopo padrão para o meu objeto Person. Veja o resultado de uma simples pesquisa por todos os registros no banco de dados:

Person.all
# => Person.find(:all, :order => 'last_name, first_name')

Isto também vale para minhas associações:

class Company < ActiveRecord::Base
  has_many :people
end

Company.find(1).people
# => Person.find(:all, :order => 'last_name, first_name', :conditions => { :company_id => 1 })

Caso seu modelo possua named_scopes, eles também incluirão as condições impostas pelo default_scope, à menos que você sobrecarregue a condição existente com alguma outra (informando uma outra ordem no exemplo acima).

Para executar uma pesquisa desconsiderando o default_scope, você deve fazer uso do método with_exclusive_scope:

Person.with_exclusive_scope { find(:all) }
# => Person.find(:all)

Para tornar o ActiveRecord mais consistente foi adicionado o método de instância Model#delete. Ele é similar ao método de classe com o mesmo nome. O método delete, diferente do método destroy, apaga o registro do banco de dados sem disparar callbacks, como o before_destroy e o after_destroy.

Este método também não aplicará nenhuma das regras impostas na associação através de cláusulas como :dependent.

client = Client.find(1)
client.delete

Não sei dizer se isto é um bug ou não, mas na minha opinião isto representa um problema. Veja o código abaixo, onde tento alterar a conta de um usuário usando sua foreign key em um projeto Rails 2.1 ou anterior:

class User < ActiveRecord::Base
  belongs_to :account
end

user = User.first
# => #<User id: 1, login: "admin", account_id: 1>

user.account
# => #<Account id: 1, name: "My Account">

user.account_id = 2
# => 2

user.account
# => #<Account id: 1, name: "My Account">

Note que estou alterando a conta do usuário, mas a associação não foi atualizada. Mesmo depois de salvar o objeto user, se ele não for recarregado, a associação continuará mostrando a conta errada.

No Rails 2.2 este problema foi corrigido, veja:

class Comment < ActiveRecord::Base
  belongs_to :post
end

comment = Comment.first
# => #<Comment id: 1>

>> comment.post
# => #<Post id: 1>

>> comment.post_id = 2
# => 2

>> comment.post
# => #<Post id: 2>

Veja que ao alterar o post por meio de sua foreign key, automaticamente a associação foi atualizada.