如何使用alembic对函数和触发器进行版本控制？

Question

假设数据库中有一个触发器，它有一个函数，如下所示：

-- Insert a new entry into another table
-- every time a NEW row is inserted
CREATE FUNCTION trgfunc_write_log() RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO some_other_table (
        -- some columns
        meter_id,
        date_taken,
        temperature,
    ) values (
        NEW.meter_id,
        NEW.time_taken,
        NEW.temperature
    );

    return NEW;
END;
$$ language 'plpgsql';

-- The trigger itself: AFTER INSERT
CREATE TRIGGER trg_temperature_readings
AFTER INSERT ON temperature_readings
FOR EACH ROW
EXECUTE FUNCTION trgfunc_write_log();

通常，此触发器将位于我的SqlAlchemy模型旁边，并使用以下内容自动创建：

from sqlalchemy import DDL, event
from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class Reading(Base):
   ...

create_trigger = DDL(""" ...SQL... """)
event.listen(Reading.__table__, 'after_create', create_trigger)

您在Alembic迁移中控制此类触发器及其功能的版本控制方面的最佳实践是什么

Answer 1

我最近在一个应用程序中遇到了同样的问题，并在Alembic食谱中找到了this article

它概述了创建一个对象的有点复杂的策略，该对象封装了用于创建视图、存储过程或触发器的名称和SQL，以及用于执行Alembic操作以升级和降级该schema对象的其他对象。在Alembic修订版中使用时，它看起来像这样：

from alembic import op
from my_module import ReplaceableObject


my_trigger = ReplaceableObject(
    "trigger_name",
    """...SQL..."""
)

def upgrade():
    op.create_trigger(my_trigger)

def downgrade():
    op.drop_trigger(my_trigger)

我的团队目前正在讨论，与视图或存储过程相比，这个策略对于简单的触发器来说是否过于复杂。您可能会更频繁地更新这些模式对象，从而使Cookbook抽象中概述的许多行为比使用简单触发器更有价值

另一个提议的方案是这样的：

from alembic import op


create_trigger = """...SQL..."""
drop_trigger = """...SQL..."""

def upgrade():
    op.execute(create_trigger)

def downgrade():
    op.execute(drop_trigger)

这两个实现看起来几乎相同，这就是Cookbook抽象对于一个简单触发器来说过于复杂的原因