Support the notion of readonly fields in a uniform manner #926
Labels
Comments
ramnivas
added a commit
that referenced
this issue
Oct 11, 2023
To support client-generated `Uuid` optionally, this PR now includes a field corresponding to the primary key for creating mutations. We need to have a formalism for this support. For example, we don't implement a similar mechanism for `autoIncrement()`ed `Int`s, since that is likely to cause confusion when a system-generated value collides with a previous user-specified value. The difference is, unlike `generate_uuid()`, `autoIncrement()` relies on database state (the underlying sequence). We can deal with it when we address #926.
ramnivas
added a commit
that referenced
this issue
Oct 11, 2023
To support client-generated `Uuid` optionally, this PR now includes a field corresponding to the primary key for creating mutations. We need to have a formalism for this support. For example, we don't implement a similar mechanism for `autoIncrement()`ed `Int`s since that is likely to cause confusion when a system-generated value collides with a previous user-specified value. The difference is, unlike `generate_uuid()`, `autoIncrement()` relies on database state (the underlying sequence). We can deal with it when we address #926.
Closed
Merged
ramnivas
added a commit
that referenced
this issue
Jun 21, 2024
Support the use cases of keeping an `updatedAt` field set to the last update time. Introduces a new `@update` annotation, which may be used as follows:
```exo
type Todo {
...
@update modificationId: Uuid = generate_uuid()
@update updatedAt: Instant = now()
}
```
The implementation is through a trigger that updates the field whenever the row is updated.
Also introduce the `@readonly` annotation to mark a field as readonly (@update implicitly marks a field as readonly).
Fixes #1090 #926 #907
|
Fixed by #1097 |
ramnivas
added a commit
that referenced
this issue
Jun 23, 2024
Support the use cases of keeping an `updatedAt` field set to the last update time. Introduces a new `@update` annotation, which may be used as follows:
```exo
type Todo {
...
@update modificationId: Uuid = generate_uuid()
@update updatedAt: Instant = now()
}
```
The implementation is through a trigger that updates the field whenever the row is updated.
Also introduce the `@readonly` annotation to mark a field as readonly (@update implicitly marks a field as readonly).
Fixes #1090 #926 #907
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Carrying over from Discord...
We support default values for fields, but their treatment varies based on the
@pkannotation. We should examine how we can make this uniform.There are three kinds of field initialization/update we need to support:
a system-specified value that users cannot specify (
@pk id: Int = autoIncrement,createdAt: Instant = now, etc. Here, we could introduce a newreadonlykeyword (but maybe infer it for the typical@pk id: Int = autoIncrementcase).have a default value, and users can specify a different one (the
@pk id: Uuid = generate_uuid()case, but also things likepublished: Boolean = false, which we already support)a special case of system-specified value (
updatedAt), which is computed by the system every time there is an update. Users cannot specify it, and it doesn't have a default either.The text was updated successfully, but these errors were encountered: