ENTONCES...

Estoy agregando tablas de historial pobladas por disparadores para auditar en mi proyecto a través 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

... y esto funcionará para la producción y otros entornos. El problema es cuando alguien correbundle exec rake db:drop db:create db:schema:load db:migrate RAILS_ENV=test o algo similar (lo más importante es eldb:schema:load parte), esto evitará la creación de activadores ya que los activadores no se guardan endb/schema.rb archivo.

Quizás la solución correcta sea decir que cuando se usan rieles, los desarrolladores nunca deberían ejecutardb:schema:load y siempre corredb:migrate en su lugar, para garantizar que todas las migraciones se puedan volver a ejecutar continuamente. Sin embargo, no hemos estado operando de esa manera durante mucho tiempo y creo que sería muy doloroso hacerlo, ya que podríamos necesitar actualizar varias docenas o más migraciones. Cualquier idea sobre cómo podría incorporar disparadores en mi aplicación de forma incremental y hacer que los entornos de desarrollador / prueba continúen siendo construidos / recreados de la misma manera que hoy sería muy útil.

¡Gracias!