Skip to content

Instantly share code, notes, and snippets.

@sorenbs
Created December 3, 2019 14:42
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save sorenbs/82dd6f7e161d328fc7e26b4143daa03c to your computer and use it in GitHub Desktop.
It seems that our thoughts on this topic are converging. I will attempt to capture all facets in a single piece of writing that we can all sign off on, and use as the basis for a pr to the schema spec.
# Relations
Relations is a high-level construct in Prisma and a key value proposition compared to other data access libraries. The relation construct is a convenient way to apply the common pattern of using keys stored in one or more fields in a model to point to a specific record of another model.
**Explicit relation** The relation can be set up explicitly by defining the referenced field:
> Note: the syntax below is omitting any details not related to the concept it explains
```prisma
model User {
name String
}
model Post {
author User @relation(references: name)
}
```
**Implicit relation** If the referenced model has a primary identifier stored in one or more fields, the field(s) do not need to be provided explicitly:
```prisma
model User {
name String @id
}
model Post {
author User
}
```
# @id
The `@id` attribute is a shorthand for the relation construct as described above.
Additionally it has two special meanings:
### the field is not nullable.
Specifically, the following syntax is not allowed:
```prisma
model User {
name String? @id
}
```
> Implementation Note: Not all connectors can provide the non-null guarantee, so the Query Engine must gracefully handle records with null-valued ids. Details to be mapped out in the spec pr.
### the field is unique
No additional syntax is required for marking the field unique. Using both `@id` and `@unique` together is disallowed:
```prisma
model User {
name String @id @unique
}
```
> Implementation Note: The Query Engine will rely on the connector providing this guarantee, and will not attempt to check for uniqueness. Not all connectors can provide the unqueness guarantee however, so the Query Engine must gracefully handle multiple records with the same id. It seems reasonable to throw an error if that condition is encountered, details to be mapped out in the spec pr.
# @default
It is possible to specify a default value that the Query Engine will insert:
### static default value
```prisma
model User {
name String @id @default("Bob")
}
```
When a default value is specified,the user can either omit or provide a value for the field when creating a record. If the field value is omitted, the default value is added by the Query Engine before the record is persisted in the database.
### dynamic default value
A static default value is not very useful for `@id` fields as they are unique. Prismas Query Engine provides a number of dynamic default values:
```prisma
model User {
name String @id @default(cuid())
}
```
Potential dynamic default values:
- time()
- date()
- random()
- cuid()
- uuid()
In the future we might support arbitrary expressions for default values.
### database assisted default values
Some default values schemes can not be implemented efficiently in the Query Engine. To address this we establish a simple agreement between the Query Engine and the database (meaning the dba or any prisma-aware migration tool such as Lift). Under this agreement, the database will do all the work, and the Query Engine will trust the database to do the right thing.
```prisma
model User {
name String @id @default(autoincrement())
}
```
Potential database assisted default values:
- autoincrement()
- dbProvided()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment