New trigger RFC

[msullivan]

Before I write up a real RFC, here's a probably half-baked initial proposal of the mutation rewrite stuff that will get split off of this. The idea Elvis and I had was that it would approximately be a generalization of default.

type Entry {
    # ...
    required property mtime -> datetime {
        rewrite insert, update using (datetime_of_statement())
    }
};

type Post {
    # ...
    multi link likes -> Like;
    required property cached_like_count -> int64 {
        rewrite insert, update using (count(.likes))
    }
};

The big question here is what all information to expose to the rewrite rules. Should we expose an __old__ thing for just updates. Should we find a way to distinguish between things that weren't specified and things what were specified as {}. How about stuff like +=?

[tailhook]

Oh, I like it so much more. Even though it probably covers smaller number of use cases, it provides much nicer interface for the most common case.

One tiny thing is, rewrite insert, update using ..., at a glance reads like "rewrite insert: do update using ..." (i.e. comma splits that into two subordinate clauses rather than groups insert and update). It's better to tweak it a little bit, for example:

• rewrite (insert, update) using ...
• rewrite using (count(.links)) on insert, update

[haikyuu]

1. Are triggers supported for abstract types? If so can I receive the concrete implementation in the trigger?

2. How do I communicate with the outside world from a trigger? Will I be able to do that from a client library?

[msullivan]

1. Are triggers supported for abstract types? If so can I receive the concrete implementation in the trigger?

Yes. Depends what you mean on the second part. You'll have access to __type__, certainly

2. How do I communicate with the outside world from a trigger? Will I be able to do that from a client library?

Probably in 4.0?

[msullivan]

@elprans @1st1 could I get an approval to merge this since I think it is a complete proposal