You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|[`ignore?`](#postgres-references-reference-ignore?){: #postgres-references-reference-ignore? } |`boolean`|| If set to true, no reference is created for the given relationship. This is useful if you need to define it in some custom way |
300
-
|[`on_delete`](#postgres-references-reference-on_delete){: #postgres-references-reference-on_delete } |`:delete \| :nilify \| :nothing \| :restrict`|| What should happen to records of this resource when the referenced record of the *destination* resource is deleted. |
300
+
|[`on_delete`](#postgres-references-reference-on_delete){: #postgres-references-reference-on_delete } |`:delete \| :nilify \| {:nilify, columns} \| :nothing \| :restrict`|| What should happen to records of this resource when the referenced record of the *destination* resource is deleted. |
301
301
|[`on_update`](#postgres-references-reference-on_update){: #postgres-references-reference-on_update } |`:update \| :nilify \| :nothing \| :restrict`|| What should happen to records of this resource when the referenced destination_attribute of the *destination* record is update. |
302
302
|[`deferrable`](#postgres-references-reference-deferrable){: #postgres-references-reference-deferrable } |`false \| true \| :initially`|`false`| Wether or not the constraint is deferrable. This only affects the migration generator. |
303
303
|[`name`](#postgres-references-reference-name){: #postgres-references-reference-name } |`String.t`|| The name of the foreign key to generate in the database. Defaults to <table>_<source_attribute>_fkey |
Copy file name to clipboardExpand all lines: documentation/topics/resources/references.md
+31-5Lines changed: 31 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,36 @@ end
14
14
>
15
15
> No resource logic is applied with these operations! No authorization rules or validations take place, and no notifications are issued. This operation happens _directly_ in the database.
16
16
17
+
## On Delete
18
+
19
+
This option describes what to do if the referenced row is deleted.
20
+
21
+
The option is called `on_delete`, instead of `on_destroy`, because it is hooking into the database level deletion, _not_ a `destroy` action in your resource. See the warning above.
22
+
23
+
The possible values for the option are `:nothing`, `:restrict`, `:delete`, `:nilify`, `{:nilify, columns}`.
24
+
25
+
With `:nothing` or `:restrict` the deletion of the referenced row is prevented.
26
+
27
+
With `:delete` the row is deleted together with the referenced row.
28
+
29
+
With `:nilify` all columns of the foreign-key constraint are nilified.
30
+
31
+
With `{:nilify, columns}` a column list can specify which columns should be set to `nil`.
32
+
If you intend to use this option to nilify a subset of the columns, note that it cannot be used together with the `match: :full` option otherwise a mix of nil and non-nil values would fail the constraint and prevent the deletion of the referenced row.
33
+
In addition, keep into consideration that this option is only supported from Postgres v15.0 onwards.
34
+
35
+
## On Update
36
+
37
+
This option describes what to do if the referenced row is updated.
38
+
39
+
The possible values for the option are `:nothing`, `:restrict`, `:update`, `:nilify`.
40
+
41
+
With `:nothing` or `:restrict` the update of the referenced row is prevented.
42
+
43
+
With `:update` the row is updated according to the referenced row.
44
+
45
+
With `:nilify` all columns of the foreign-key constraint are nilified.
46
+
17
47
## Nothing vs Restrict
18
48
19
49
```elixir
@@ -24,8 +54,4 @@ references do
24
54
end
25
55
```
26
56
27
-
The difference between `:nothing` and `:restrict` is subtle and, if you are unsure, choose `:nothing` (the default behavior). `:restrict` will prevent the deletion from happening _before_ the end of the database transaction, whereas `:nothing` allows the transaction to complete before doing so. This allows for things like updating or deleting the destination row and _then_ updating updating or deleting the reference(as long as you are in a transaction). The reason that `:nothing` still ultimately prevents deletion is because postgres enforces foreign key referential integrity.
28
-
29
-
## On Delete
30
-
31
-
This option is called `on_delete`, instead of `on_destroy`, because it is hooking into the database level deletion, _not_ a `destroy` action in your resource. See the warning above.
57
+
The difference between `:nothing` and `:restrict` is subtle and, if you are unsure, choose `:nothing` (the default behavior). `:restrict` will immediately check the foreign-key constraint and prevent the update or deletion from happening, whereas `:nothing` allows the check to be deferred until later in the transaction. This allows for things like updating or deleting the destination row and _then_ updating updating or deleting the reference (as long as you are in a transaction). The reason that `:nothing` still ultimately prevents the update or deletion is because postgres enforces foreign key referential integrity.
0 commit comments