TÃO...

Estou adicionando tabelas de histórico preenchidas por gatilhos para auditoria no meu projeto por meio de algo como ...

execute <<-SQL
  CREATE OR REPLACE FUNCTION process_history_table() RETURNS TRIGGER AS $history_table$
    BEGIN
      IF (TG_OP = 'DELETE') THEN
          INSERT INTO history_table VALUES (DEFAULT, 'D', now(), OLD.*);
          RETURN OLD;
      ELSIF (TG_OP = 'UPDATE') THEN
          INSERT INTO history_table VALUES (DEFAULT, 'U', now(), NEW.*);
          RETURN NEW;
      ELSIF (TG_OP = 'INSERT') THEN
          INSERT INTO history_table VALUES (DEFAULT, 'I', now(), NEW.*);
          RETURN NEW;
      END IF;
      RETURN NULL; -- result is ignored since this is an AFTER trigger
    END;
  $history_table$ LANGUAGE plpgsql;

  CREATE TRIGGER history_table
  AFTER INSERT OR UPDATE OR DELETE ON table
    FOR EACH ROW EXECUTE PROCEDURE process_history_table();
SQL

... e isso funcionará para produção e outros ambientes. O problema é quando alguém correbundle exec rake db:drop db:create db:schema:load db:migrate RAILS_ENV=test ou algo semelhante (o mais importante é odb:schema:load ), isso ignorará a criação do gatilho, pois os gatilhos não são salvos nodb/schema.rb Arquivo.

Talvez a solução correta seja dizer que, ao usar trilhos, os desenvolvedores nunca devem executardb:schema:load e sempre corradb:migrate em vez disso, para garantir que todas as migrações possam ser repetidas continuamente. No entanto, não estamos operando dessa maneira há muito tempo e acredito que seria bastante doloroso fazê-lo, pois podemos precisar atualizar várias dezenas ou mais migrações. Quaisquer pensamentos sobre como incorporar gatilhos no meu aplicativo de forma incremental e fazer com que os ambientes de desenvolvedor / teste continuem sendo criados / recriados da mesma maneira que hoje seriam muito úteis.

Obrigado!