RFC 1021: Mutation rewrites

[tailhook]

Looking at @aljazerzen questions, I'm thinking, maybe it should be an extension of the default instead. Here are two examples of how it might look like:

property change_timestamp -> datetime {
    default := datetime_of_statement();
    use default on update;
}

Or:

property change_timestamp -> datetime {
    default (on insert, update) := datetime_of_statement();
}

Since it's a "default", UPDATE .. SET { change_timestamp := $x } obviously overrides it. And I don't think we need a syntax that explicitly overrides what user specified in query. This is not column-based ACL.

It can also have other fields specified syntactically:

property cached_friend_count -> datetime {
    default := count(__subject__.friends);
    use default on update of .friends;
    #                        ^^^^^^^^ --- this field is tracked by a compiler
}

So renaming a link/property works in DDL and is a compiler error in SDL (unless property is fixed).

[tailhook]

I also think that some examples, like this (including mine):

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

Are better written as a cached computed property:

      multi link likes -> Like;
      cached property cached_like_count := count(.likes);
#     ^^^^^^ -- just a specifier on a computed property

In this case, compiler can figure out itself that it depends on .likes and recompute when that link is changed.

This means that applicability of this rewrite is basically only on calling functions with side-effects. Which kinda an argument to make it just a simple extension of default like I've proposed above.

[elprans]

@tailhook one problem of extending default like this is that the semantics isn't clear. Generally, a "default" is used when a value is empty, whereas in the proposed design it would overwrite possibly non-empty values on update.

[elprans]

Another capability that the RFC does yet show is the actual rewrite, i.e. the ability to alter specified incoming data. One case would be providing data-format level compatibility, i.e. accepting some "old" format and automatically rewriting it into "new" format, thus supporting old API clients. This is what a "default extension" approach wouldn't be able to support.

[msullivan]

Another capability that the RFC does yet show is the actual rewrite, i.e. the ability to alter specified incoming data. One case would be providing data-format level compatibility, i.e. accepting some "old" format and automatically rewriting it into "new" format, thus supporting old API clients. This is what a "default extension" approach wouldn't be able to support.

Oh yeah, this is a great point. I'll add an example along those lines.

[msullivan]

The thing I don't love about the cached proposal is that it kind of promises more than it can deliver