Anton
May 23, 2021, 9:46pm
1
Hello
I’d like to be able to store the created time and date for a Graphql type, ideally with a default value, in the schema.
The goal, too, is to avoid the client application having to send the created value, which could also be an inaccurate value.
In Sql this can be achieved using something similar to created TIMESTAMP DEFAULT NOW().
Is it possible to do something similar in Graphql?
They have not added this feature yet (very important IMHO), though they hinted at sometime this year…
Thank you for this well thought out push for server-side timestamps!
I love this. Would help a lot with getting only newest data and not receiving old data from sub-graphs over and over again.
Does this need to be so strict? Why not allow both? For instance, we would definitely need mutable timestamps for client ↔ server synchronization.
When implemented like this, you could choose to allow it or not:
type TimestampConfig {
active: Boolean!
mutable: Boolean!
}
@timestamps( createdAt:…
In the meantime, the best route is to use a hook with something like addPostWebhook . Keep in mind, for the moment it only supports post-hooks (hopefully pre-hooks one day). This should be up on Cloud DGraph by the end of the week with 21.03 :
Basically, you would just add a createdAt value after the rest of the field is created, and you could add updatePostWebhook with updatedAt value for after a field is updated. If someone passed in a date, you could reject the call, or simply replace the value with the correct date and not worry about it.
J
Anton
May 23, 2021, 10:51pm
3
Thank you J
The Lambda webhooks does look like a solution, though it is a lot more work than simply setting a default value. That being said, the web hooks do offer much more capabilities.
Thank you for your prompt and helpful response!
1 Like
ansonhwang
January 12, 2022, 1:41am
4
The @defualt derective is avairable in v21.12
dgraph-io:master ← dpeek:graphql-timestamps
opened 07:53AM - 07 Sep 21 UTC
Adds support for `@default` directive to GraphQL input schema.
Syntax:
```… graphql
type Type {
field: FieldType @default(
add: {value: "value"}
update: { value: "value"}
)
}
```
Where a value is not provided as input for a mutation, the `add` value will be used if the node is being created, and the `update` value will be used if the node exists and is being updated. Values are provided as strings, parsed into the correct field type by Dgraph.
The string `$now` is replaced by the current DateTime string on the server, ie:
```graphql
type Type {
createdAt: DateTime! @default(
add: { value: "$now" }
)
updatedAt: DateTime! @default(
add: { value: "$now" }
update: { value: "$now" }
)
}
```
Schema validation will check that:
- `Int` field values can be parsed `strconv.ParseInt`
- `Float` field values can be parsed by `strconv.ParseFloat`
- `Boolean` field values are `true` or `false`
- `$now` can only be used with fields of type `DateTime` (could be extended to include `String`?)
Schema validation does not currently ensure that `@default` values for enums are a valid member of the enum, so this is allowed:
```graphql
enum State {
HOT
NOT
}
type Type {
state: State @default(add: { value: "FOO"})
}
```
Schema validation also prevents use of `@default` on:
- Types with `@remote` directive
- Fields of type `ID`
- Fields that are not scalar types (`Int`, `Float`, `String`, `Boolean`, `DateTime`) or an enum
- Fields that are list types (ie `[String])
- Fields with `@id`, `@custom`, `@lambda`
Output schema changes:
- Fields with `@default(add)` values become optional in `AddTypeInput`
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/dgraph-io/dgraph/8017)