Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the notion of readonly fields in a uniform manner #926

Open
ramnivas opened this issue Oct 8, 2023 · 0 comments
Open

Support the notion of readonly fields in a uniform manner #926

ramnivas opened this issue Oct 8, 2023 · 0 comments
Labels

Comments

@ramnivas
Copy link
Contributor

ramnivas commented Oct 8, 2023

Carrying over from Discord...

We support default values for fields, but their treatment varies based on the @pk annotation. 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 new readonly keyword (but maybe infer it for the typical @pk id: Int = autoIncrement case).

  • have a default value, and users can specify a different one (the @pk id: Uuid = generate_uuid() case, but also things like published: 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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant