Posts Tagged 'activerecord'

Rails sem banco de dados

Post movido para: http://blog.guilhermegarnier.com/2008/06/17/rails-sem-banco-de-dados/

O Active Record é um dos principais componentes do Rails, pois é exatamente o model do MVC. Ele mapeia automaticamente uma classe numa tabela do banco de dados, criando métodos para acesso a cada atributo. Porém, e se quisermos desenvolver uma aplicação sem banco de dados?

Passei por esta situação recentemente: a aplicação acessa um servidor diretamente, via Atom, e, portanto, não precisa armazenar dados localmente. Porém, não basta comentar todas as linhas do arquivo config/database.yml, pois o Rails mostrará uma mensagem de erro informando que não encontrou o banco de dados correspondente.

Para resolver este problema, resolvi, inicialmente, tentar não utilizar o Active Record. Para isso, primeiramente precisei modificar o model que eu tinha na aplicação, retirando a herança de ActiveRecord::Base. Porém, ao tentar executar o servidor, recebi mensagens de erro informando que o banco de dados não foi encontrado. Isso ocorre porque, apesar de não haver qualquer classe herdando de ActiveRecord::Base no projeto, este módulo estava sendo carregado. Conseqüentemente, o Rails tentava ler o arquivo config/database.yml, que não estava configurado, resultando na mensagem de erro. Para evitar este problema, foi necessário evitar o carregamento do ActiveRecord explicitamente, acrescentando a linha abaixo ao arquivo config/environment.rb:

config.frameworks -= [ :active_record ]

Feito isto, o Rails passa a funcionar sem banco de dados e sem ActiveRecord. Porém, surgiu um outro problema: os testes unitários do Rails pararam de funcionar, pois a classe ActiveSupport::TestCase, que é a classe base para os testes unitários, não funciona sem ActiveRecord. Para resolver, troquei a herança desta classe para Test::Unit::TestCase, que era utilizada como padrão antes da versão 2 do Rails. Não sei exatamente quais são as diferenças entre as duas, mas só consegui resolver este problema desta forma – se alguém descobrir alguma outra solução, me avise!

Também precisei carregar explicitamente o model no arquivo de teste, pois o Rails deixou de fazer a referência automática a esta classe. Feitas as alterações, o arquivo de teste (ex: test/unit/usuario_test.rb) ficou assim:

require 'test/test_helper'
require 'test/unit'
require 'app/models/usuario'

class UsuarioTest < Test::Unit::TestCase
  # Replace this with your real tests.
  def test_truth
    assert true
  end
end
Anúncios

Configurações fora do padrão em Rails, parte 2 – Relacionamentos HABTM

Post movido para: http://blog.guilhermegarnier.com/2008/04/10/configuracoes-fora-do-padrao-em-rails-parte-2-relacionamentos-habtm/

Há um mês escrevi um post sobre configurações fora do padrão em Rails, onde descrevi como executar testes com models cujas tabelas não existem no banco de dados local, e sim em uma base externa. Porém, depois de postar, verifiquei que há um outro problema não resolvido com a configuração que descrevi nesse post: relacionamentos HABTM (has and belongs to many).

Nos relacionamentos HABTM, normalmente, há dois models, um correspondente a cada tabela do banco de dados. Como a relação entre eles é de muitos para muitos, há uma terceira tabela no banco de dados, que é responsável pela associação das demais tabelas. Como essa tabela só costuma ter dois campos, que são FK’s correspondentes às PK’s dessas tabelas, ela não precisa ter um model; basta criar o relacionamento dos dois models como has_and_belongs_to_many, passando como parâmetro join_table essa tabela intermediária.

A configuração descrita no post anterior carrega manualmente os fixtures de cada model, porém não carrega fixtures correspondentes à tabela intermediária. Para isso, precisei implementar um novo método na classe Test::Unit::TestCase (arquivo test/test_helper.rb):

def set_habtm_fixtures(class1, class2)
  return unless (class1.reflections && class1.reflections.values)
  id1 = nil
  id2 = nil
  table = nil

  # Verifica qual dos relacionamentos do model class1 está associado à tabela class2
  class1.reflections.values.each do |r|
    # Se a classe associada for class2 e for uma relação HABTM, le os FK's e o nome da tabela
    if (r.klass == class2 && !r.instance_values['options'][:join_table].nil?)
      id1 = r.primary_key_name
      id2 = r.association_foreign_key
      table = r.instance_values['options'][:join_table]
      break
    end
  end
  return if table.nil?
  connection = class1.connection

  data = File.open(File.join(RAILS_ROOT, 'test', 'fixtures', "#{table}.yml")).readlines.join
  result = ERB.new(data).result
  parsed = YAML.load(result)

  # Exclui todos os registros da tabela
  connection.execute "DELETE FROM #{table}"

  parsed.values.each do |value|
    value1 = value[id1] || 'NULL'
    value2 = value[id2] || 'NULL'
    connection.execute "INSERT INTO #{table} (#{id1}, #{id2}) values (#{value1}, #{value2})"
  end
end

Este método ficou bem “feio”, pois, como não existe um model correspondente a esta tabela, precisei criar a query manualmente. O método recebe dois nomes de classes (ActiveRecord) como parâmetro. Primeiramente é verificado qual dos relacionamentos do model class1 está associado a class2, para descobrir quais são as FK’s e o nome da tabela. Em seguida, os registros desta tabela são excluídos, e cada linha do arquivo de fixtures é carregada (usando a conexão de um dos ActiveRecords).

Além disso, modifiquei o método set_fixtures desta mesma classe, criado no post anterior, pois percebi que não era necessário passar o nome da tabela como parâmetro, basta usar o método table_name:

def set_fixtures (class_name)
  table = class_name.table_name
  return unless class_name.kind_of?(ActiveRecord::Base)

  # Define a conexao usada pela classe
  ActiveRecord::Base.connection = base.connection
  Fixtures.create_fixtures(File.join(RAILS_ROOT, 'test', 'fixtures'), table) { base.connection }
end

Para exemplificar como usar estes métodos, imagine um cadastro de usuários com grupos, onde um usuário pode fazer parte de mais de um grupo. Neste exemplo, teríamos um model Usuario (tabela usuarios), um model Grupo (tabela grupos) e uma tabela usuarios_grupos, sem um model correspondente. Na classe de teste do model Usuario, teríamos o seguinte:

class UsuarioTest < ActiveSupport::TestCase
  def setup
    set_fixtures(Usuario)
    set_fixtures(Grupo)
    set_habtm_fixtures(Usuario, Grupo)
  end

  # Testes
end

No método setup, que é executado automaticamente quando os testes são executados, as duas chamadas a set_fixtures carregam as fixtures das tabelas de usuários e grupos, respectivamente; a chamada a set_habtm_fixtures atualiza a tabela usuarios_grupos.

Configurações fora do padrão em Rails

Post movido para: http://blog.guilhermegarnier.com/2008/03/18/configuracoes-fora-do-padrao-em-rails/

O framework Rails é excelente na tarefa de automatizar o máximo possível o desenvolvimento de aplicações web. Todos os detalhes que podem ser implementados automaticamente são abstraídos do desenvolvedor, facilitando e agilizando muito o trabalho.

Porém, toda essa automatização e abstração de detalhes internos tem um custo, que é a padronização. Por exemplo, ao usar o script generate para criar um model, o Rails cria uma classe derivada de ActiveRecord::Base. Os nomes do arquivo, da classe e da tabela são automaticamente gerados a partir do parâmetro passado. Ex:

ruby script/generate model tipo_usuario

Arquivo: tipo_usuario.rb

Classe: TipoUsuario

Tabela: tipo_usuarios

Neste caso, a partir do parâmetro passado para o script, o nome do arquivo é o próprio parâmetro com “.rb” no final, o nome da classe é gerado retirando-se os “_” e colocando a primeira letra de cada palavra em maiúscula, e o nome da tabela é o plural – que pode ser redefinido no arquivo config/initializers/inflections.rb:

Inflector.inflections do |inflect|
  inflect.irregular 'tipo_usuario', 'tipos_usuario'
end

Com a configuração acima, o nome da tabela será tipos_usuario – desde que esta configuração seja realizada antes do generate!

O principal problema que esta padronização traz é que nem sempre queremos/podemos seguir o padrão de configuração gerado pelo Rails. Na maioria das situações, é possível definir explicitamente quando se quer usar uma configuração diferente, como no caso do plural da tabela acima. O nome da tabela associado a um model também pode ser alterado, através do método set_table_name. Desta forma, o Rails não amarra totalmente o desenvolvedor aos seus padrões.

Porém, apesar da flexibilidade, essas configurações fora dos padrões nem sempre funcionam como deveriam. Muitas vezes, ocorre algum “efeito colateral” que faz com que algum outro módulo não funcione corretamente. Conforme escrevi no post Acessando múltiplos bancos de dados em Rails, ao configurar o acesso a múltiplos bancos de dados, os unit tests pararam de funcionar. Mais uma vez, precisei passar algum tempo pesquisando no Google para encontrar uma solução.

O primeiro problema é com os fixtures. Quando o nome da tabela é diferente do model, o nome do arquivo de fixtures deve ser igual ao nome da tabela seguido por “.yml”. Nos unit tests, o símbolo passado para o método fixtures deve ter este nome. No artigo sobre acesso a múltiplos bancos de dados, citei como exemplo uma tabela usuario_tb. Neste caso, o arquivo de fixtures deveria se chamar usuario_tb.yml, e o arquivo com unit tests deveria carregar esses fixtures assim:

class UsuarioTest < ActiveSupport::TestCase
  fixtures :usuario_tb
end

Em casos onde a única configuração fora do padrão seja o nome da tabela, a configuração acima é suficiente. Porém, no caso do exemplo citado no artigo anterior, onde o model não é mapeado numa tabela local, e sim num outro banco de dados, surgem outros problemas. O primeiro é que, ao tentar executar os testes, o rake informa que a tabela não existe. A única maneira que descobri para corrigir este problema foi criar esta tabela no ambiente de desenvolvimento. Ela não é usada para nada, mas se não for criada, os testes não funcionarão.

O segundo problema com esta configuração é que não é possível carregar os fixtures da maneira descrita acima. Em vez disso, é necessário usar o método create_fixtures da classe Fixtures. Para simplificar, como podem haver mais models configurados desta maneira, fiz a seguinte configuração:

1 – criar o método set_fixtures no arquivo test/test_helper.rb:

def set_fixtures (table, base)
  return unless (table && base.kind_of?(ActiveRecord::Base))

  ActiveRecord::Base.connection = base.connection
  Fixtures.create_fixtures(File.join(RAILS_ROOT, 'test', 'fixtures'), table) { base.connection }
end

2 – criar o método setup nos unit tests, utilizando esse método para cada arquivo de fixtures que será carregado:

def setup
  set_fixtures('usuario_tb', AutenticacaoDatabase)
end

No código acima, AutenticacaoDatabase é a classe abstrata usada como base para o model Usuario.

Com essas configurações é possível realizar os testes, com um único problema: não é possível referenciar os fixtures pelos labels. Para simplificar, como ainda não descobri uma maneira de corrigir isto, eu costumo definir os labels dos fixtures como números seqüenciais, começando em 0. Assim eu posso buscar todos os dados da tabela (ex: Usuario.find(:all)) e referenciar o array pelos índices, que, neste caso, correspondem aos labels. Mas cuidado: o find(:all) não garante que o array retornado terá a mesma ordem do arquivo de fixtures. O ideal é criar fixtures com id seqüencial, e adicionar o parâmetro order ao find.

Referências:

Acessando múltiplos bancos de dados em Rails

Post movido para: http://blog.guilhermegarnier.com/2008/03/11/acessando-multiplos-bancos-de-dados-em-rails/

Esta semana me deparei com uma situação no projeto em Rails em que estou trabalhando, onde necessitei acessar um banco de dados de outra aplicação, para fazer algumas consultas simples. Eu poderia simplesmente fazer a conexão com o banco e as querys em SQL. Porém, eu obviamente queria aproveitar as facilidades que o Rails proporciona ao abstrair estes detalhes com a classe ActiveRecord::Base.

Quando criamos um novo model em Rails, a nova classe criada, derivada de ActiveRecord::Base, é mapeada por padrão em uma tabela no banco de dados da aplicação – o Rails assume o nome da classe no plural, mas permite que você especifique um nome diferente. Na migration que também é criada automaticamente, a tabela correspondente é definida. Porém, neste caso, eu não queria criar uma tabela, pois ela já existe. Além disso, é um servidor de banco de dados diferente, com usuário e senha diferentes.

Após alguma pesquisa, descobri como resolver este problema. Suponha que você queira acessar uma base de usuários para compartilhar login e senha:

1 – especificar a nova conexão no arquivo config/database.yml. No exemplo abaixo, defini o nome “autenticacao_development”, supondo que tenhamos outras conexões para teste e produção:

autenticacao_development:
  adapter: mysql
  host: autenticacao_dev
  username: login
  password: senha
  database: autenticacao

2 – criar uma classe abstrata (model), derivada de ActionRecord::Base, e usar o método establish_connection para referenciar a conexão. O parâmetro “autenticacao_#{RAILS_ENV}” usa a variável RAILS_ENV para especificar a conexão relativa ao ambiente (autenticacao_development, autenticacao_test ou autenticacao_production):

class AutenticacaoDatabase < ActiveRecord::Base
  self.abstract_class = true
  establish_connection "autenticacao_#{RAILS_ENV}"
end

3 – para cada tabela deste banco de dados que será acessada, criar uma nova classe (model) derivada da classe AutenticacaoDatabase recém-criada. Caso o nome da tabela seja diferente do padrão (o nome da classe no plural), use o método set_table_name para especificar o nome correto. E se a primary key não for “id”, use “set_primary_key” para definir o nome correto deste campo.

class Usuario < AutenticacaoDatabase
  set_table_name 'usuario_tb'
  set_primary_key 'usuario_id'
end

Feitas as configurações acima, o banco de dados externo ficará acessível como o da aplicação, com todos os métodos usados normalmente. Por exemplo:

Usuario.find(:all)
Usuario.find_by_usuario_id(1)
Usuario.create

Detalhe importante: com esta configuração, é necessário fazer uma série de alterações nos unit tests para que estes funcionem. Em breve farei outro post detalhando estes passos.

Seguem abaixo os links que eu usei como base:


@guilhermgarnier

Erro: o Twitter não respondeu. Por favor, aguarde alguns minutos e atualize esta página.

Estatísticas

  • 58,410 hits
Linux Counter