Migrações de dados em Ruby on Rails
Tags: ruby, rails, database, backend
Published: 2022-03-10 13:36:54

Desde o início dessa minha caminhada como desenvolvedor Ruby on Rails, eu venho aprendendo determinadas técnicas e ferramentas que me auxiliam no meu dia a dia. Uma vez no meu trabalho, ocorreu a necessidade de alterar os dados reais no banco de dados de produção. Eu pensei rapidamente e a primeira opção óbvia que vem à mente é usar uma migração do Rails, porém conversando com colegas da minha equipe, fui convencido de que isso não seria uma boa prática e a partir daí busquei entender um pouco mais sobre como migrar dados de maneira correta e mais segura utilizando `Ruby on Rails`.

## Utilizando o sistema de migrações do Rails


Observando o _[Rails Guide, for Active Record Migration](https://guides.rubyonrails.org/active_record_migrations.html)_ a primeira seção da documentação começa dizendo:

> _"As migrações são um recurso do Active Record que permite evoluir seu esquema de banco de dados ao longo do tempo. Em vez de escrever modificações de esquema em SQL puro, as migrações permitem que você use uma DSL Ruby para descrever as alterações em suas tabelas."_

Claramente, a palavra "dados" em nenhum momento foi citada no parágrafo acima, isso porque, por definição, as migrações do Rails devem ser usadas apenas para alterações do `schema` e não para alterações de dados reais no banco de dados.

Podemos criar um cenário básico para entendermos um pouco mais sobre isso. Digamos que nós precisamos alterar o estado padrão de um blog qualquer, por exemplo, sendo assim criaríamos um arquivo de migração como este abaixo:

```ruby
rails generate migration ChangeDefaultState
  invoke  active_record
  create    db/migrate/20220305055147_change_default_state.rb

```
Nesse arquivo, faríamos a seguinte alteração como essa:

```ruby
class ChangeDefaultState < ActiveRecord::Migration[5.1]
  def up
    Post.where(state: "Initial").update_all(state: "Active")
  end

  def down
    raise ActiveRecord::IrreversibleMigration
  end
end
```
Feito isso, está tudo certo! É só executar a migração e esquecer dela... Meses depois aparece uma demanda no seu sistema, onde nós precisamos alterar o nome da tabela `posts` para `articles`. Até então é uma tarefa simples de ser executada. Alterando o nome da tabela, renomeando o modelo e pronto, só mandar para produção. Pois bem, agora nós não temos mais um modelo chamado `Post`. Na próxima vez que você precisar configurar um ambiente de desenvolvimento, você cria seu banco de dados, executa suas migrações e obtém uma falha no seu console: Rails não sabe o que é `Post`:


```ruby
$ rails db:migrate
== 20220305056456 AddDefaultState: migrating ==================================
rails aborted!
StandardError: An error has occurred, this and all later migrations canceled:
uninitialized constant AddDefaultState::Post
/Users/lucas/Projects/codes/serious/db/migrate/20220305055147_change_default_state.rb:3:in `change'
```
A solução para esse tipo de problema, de fato, é rápida: você precisa renomear o modelo na sua migração. Entretanto esse padrão não é a melhor abordagem. Resumidamente,as migrações ficam desatualizadas rapidamente e você não tem uma maneira eficiente de descobrir, além do mais não estaria seguindo a convenção do Rails: os arquivos `db/migrate` devem migrar apenas as estrutura do banco de dados e não os registros do banco de dados. 

Outro detalhe é que o sistema agora  depende da conclusão da migração de dados. Isso pode não ser um problema quando seu aplicativo é novo e seu banco de dados é pequeno. Mas e os grandes bancos de dados com milhões de registros? Sua implantação agora terá que esperar que a manipulação de dados seja concluída e isso é apenas pedir problemas, com possíveis migrações suspensas ou com falha. Dito isso, pode-se dizer que incluir os códigos de migração de dados no `db:/migrate` é uma prática "anti-padrão".

## Utilizando Rake Tasks para migrar dados

Um método mais confiável, acessível e eficiente é criar `Rake Tasks` para migrações de dados. Escrevendo um pouco mais de código nós podemos resolver esse tipo de problema.

```ruby
namespace :data do
  task :migrations do
    Rake.application.in_namespace(:data) do |namespace|
      namespace.tasks.each do |t|
        next if t.name == "data:migrations"
        puts "Invoking #{t.name}:"
        t.invoke
      end
    end
  end

  task change_default_state: :environment do
    puts "Changing default state for posts"
    Post.where(state: "Initial").update_all(state: "Active")
    puts "Changed default state for posts"
  end
```

A primeira `Task` ( rake data:migrations) executará todas as tarefas no data namespace excluindo ela mesma. Isso pode ser um pouco arriscado! então você deve se certificar de que todas as `Tasks` nesse namespace sejam idempotentes, ou seja, realizadas com sucesso independente do número de vezes que é executada. Você deseja poder executar `rake data:migrations` o quanto quiser sem arriscar a perda de dados.

A ressalva que temos com essa abordagem é que ela não resolve o problema que mencionamos no primeiro padrão: à medida que o sistema evolui, as `Tasks` ficarão desatualizadas.

A melhor maneira é criar uma classe adicional. Podemos chamá-lo` ChangeDefaultStateForPosts`. Será um objeto `Ruby` simples que executará a migração de dados. Isso nos ajudará a adicionar cobertura de testes para ele.

```ruby
class ChangeDefaultStateForPosts
  def self.call
    Post.where(state: "Initial").update_all(state: "Active")
  end
end
```
Agora que temos uma classe simples e com isso podemos escrever um arquivo de testes para ela.

```ruby
RSpec.describe ChangeDefaultStateForPosts do
  describe "ChangeDefaultStateForPosts.call" do
    let!(:post) do
      Post.create(state: state)
    end

    context "when post is in 'Initial' state" do
      let(:state) { "Initial" }

      it "changes the state of the Initial" do
        expect do
          ChangeDefaultStateForPosts.call
        end.to change(post, :state)
      end
    end

    context "when post is in another state" do
      let(:state) { "Published" }

      it "doesn't change the state" do
        expect do
          ChangeDefaultStateForPosts.call
        end.not_to change(post, :state)
      end
    end
  end
end

```
Sendo assim estamos seguros pois a nossa `Task` sobre a migração de dados é protegidas pelo nosso arquivo de teste. Quando alguém tentar renomear a tabela `posts` para `articles`, receberá uma falha no teste. Isso os forçará a atualizar o arquivo de migração de dados.

Caso essa opção seja válida e queira implementar no seu projeto, é bastante recomendado documentar todo esse processo.

## Migrações de dados com a `data_migrate`

Como todo desenvolvedor Rails, provavelmente, em algum momento desse artigo, você chegou a se perguntar se talvez existisse uma Gem para fazer esse processo de migração de dados... SIM, nós podemos usar a [data_migrate](https://github.com/ilyakatz/data-migrate) para todas as nossas migrações de dados. Assim como o Rails com a tabela `schema_migrations`, a [data_migrate](20220305055147) usa uma tabela especifica chamada `data_migrations` para acompanhar as migrações novas e as antigas.

Para o problema que estamos tentando resolver, você pode criar uma nova migração de dados como esta:

`rails generate data_migration change_default_state_for_posts`

Isso adicionará uma nova migração de dados ao diretório `db/data`. Você precisará definir os métodos `up` e `down`:

```ruby
class ChangeDefaultStateForPosts < ActiveRecord::Migration[5.1]
  def up
    Post.where(state: "Initial").update_all(state: "Active")
  end

  def down
    Post.where(state: "Active").update_all(state: "Initial")
  end
end
```

E, em seguida, execute e verifique o status com comandos como estes:

```ruby
rake data:migrate
rake db:migrate:with_data
rake db:rollback:with_data
rake db:migrate:status:with_data

```

Acredito que a melhor maneira de resolver esse problema é usar a Gem [data_migrate](https://github.com/ilyakatz/data-migrate). Você escreverá menos código, manterá todas as migrações de dados em um diretório  `db/data` e terá uma boa maneira de acompanhar as alterações de dados.