Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Commit e442f40

Browse files
committed
Add note re non-transactional mutations
1 parent 8ca29dc commit e442f40

File tree

1 file changed

+35
-0
lines changed

1 file changed

+35
-0
lines changed

README.md

+35
Original file line numberDiff line numberDiff line change
@@ -131,6 +131,41 @@ schemas with nullable types (ones whose marked with asterisk). Mutations still
131131
can be enabled with the `enable_mutations = true` option, but use it with
132132
caution. Don't enable this option with schemas involve nullable types.
133133

134+
#### Mutations with space accessor
135+
136+
TBD: Describe which changes are transactional and which views are guaranteed to
137+
be consistent.
138+
139+
#### Mutations with shard accessor
140+
141+
Mutations are disabled in the resharding state of a shard cluster.
142+
143+
There are three types of modifications: insert, update and delete. Several
144+
modifications are allowed in an one GraphQL request, but they will be processed
145+
in non-transactional way.
146+
147+
In the case of shard accessor the following constraints can guarantee that data
148+
will be changed in atomic way or, in other words, in an one shard request (but
149+
foregoing and upcoming selects can see other data):
150+
151+
* One insert / update / delete argument over the entire GraphQL request.
152+
* For update / delete: either the argument is for 1:1 connection or `limit: 1`
153+
is used for a collection (a topmost field) or 1:N connection (a nested
154+
field).
155+
* No update of a first field of a **tuple** (shard key is calculated by it). It
156+
is the first field of upmost record in the schema for a collection in case
157+
when there are no service fields. If there are service fields, the first
158+
field of a tuple cannot be changed by a mutation GraphQL request.
159+
160+
Data can be changed between shard requests which are part of the one GraphQL
161+
request, so the result can observe inconsistent state. We'll don't show all
162+
possible cases, but give an idea what going on in the following paragraph.
163+
164+
Filters are applied for an object(s) (several requests in case of filters by
165+
connections, one request otherwise), then each object updated/deleted by its
166+
primary key (one request per object), then all connected objects are resolved
167+
in the same way.
168+
134169
#### Insert
135170

136171
Example with an object passed from a variable:

0 commit comments

Comments
 (0)