Triggers

[gronke]

Issue #403 discusses ideas and interfaces to implement SQL triggers. Inspired by this conversation, this pull-request suggests a way to implement triggers.

This PR is in an early stage and meant to provide surface for discussion and tinkering.

// the most simple way to create a trigger
let unnamed_trigger: UnnamedTrigger =  UnnamedTrigger::new();

// it can be named later, and become a NamedTrigger
let named_trigger: NamedTrigger = unnamed_trigger.name("my_trigger");

// this is useful because it allows dropping directly
let drop_sql: String = named_trigger.drop().to_string(MysqlQueryBuilder);

// with a table, action and action time we dare do derive a trigger name
let trigger: DefinedTrigger = unnamed_trigger.before_insert(Glyph::Table);
assert_eq!(trigger.trigger_name(), "t_glyph_before_insert");

// demo expression, blocked by missing features (e.g. IF-ELSE statements)
let action: SimpleExpr = Expr::col(Glyph::Id).eq(1);

// multiple actions will be executed in order of insertion
trigger.actions.push(action);

println!(trigger.create().to_string(MysqlQueryBuilder));

CREATE TRIGGER `t_glyph_before_insert` BEFORE INSERT ON `glyph` FOR EACH ROW
BEGIN
`id` = 1;
END

The action expression (between BEGIN and END) does not make sense yet and exists to outline the idea. With new features to express logic, variable declaration, loops and custom errors this could be achieved though.

New Features

• Create and drop TRIGGER
• Named and unnamed triggers (name derived from table, action and time)
• Concatenate list of statements

TBD

• Missing statement implementations
  • IF-ELSE statements
  • LOOP
  • custom SQL errors
• Use wrappers around triggers to polyfill CKECK constraints for MySQL and Sqlite
• Buil unit-tests for PostgreSQL and SQlite3
• Address IF NOT EXISTS differences between database backends + write unit-tests
• Integration testing against live backends before engaging in fancy feature wrappers

[pcwizz]

It would be nice to have statement level triggers although they aren't available in mysql.

[HigherOrderLogic]

How about unifying the two into one with fn named(...) and fn unnamed(...)?

[gronke]

The two structs UnnamedTrigger and NamedTrigger are distinguished because of slightly different interfaces. Generating trigger names is only needed when a user did not specify an explicit name. Differentiating structs within the Trigger enum allows auto-completion.

The Trigger implementation has two methods new and with_name that are similar to your suggestion:

impl Trigger {
    pub fn new() -> Trigger {
        Trigger::UnnamedTrigger(None, None, None)
    }

    pub fn with_name(name: TriggerRef) -> Trigger {
        Trigger::NamedTrigger(name, None, None, None)
    }
}

@HigherOrderLogic do you think we should get rid of the two variants and accept that users might inadvertently use unnamed triggers? Typically I prefer being explicit, but I also see the potential to reduce complexity. Happy to hear your suggestion. 😊

[HigherOrderLogic]

do you think we should get rid of the two variants and accept that users might inadvertently use unnamed triggers

I think that an unified enum would be better for end users DX, however, I disagree that unnamed should be the default.

As I stated in the previous comment, we can implement different functions for each variants, eg:

impl Trigger {
    pub fn unnamed() -> Trigger {
        Trigger::UnnamedTrigger(None, None, None)
    }

    pub fn named(name: TriggerRef) -> Trigger {
        Trigger::NamedTrigger(name, None, None, None)
    }
}