I'm submitting a ...
4.0.0-alpha2.28
CREATE TABLE foo (
id integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
bar text NOT NULL
);
Config: classicIds: true
Mutation
mutation updateFooMutation($input: UpdateFooInput!) {
updateFoo(input: $input) {
clientMutationId
fooEdge {
cursor
node {
id
bar
}
}
}
}
Query Variables
{
"input": {
"clientMutationId": "base-64-encoded-identifier",
"id": "base-64-encoded-tuple",
"fooPatch": {
"bar": "baz"
}
}
}
The cursor field returns null.
{
"data": {
"updateFoo": {
"clientMutationId": "base-64-encoded-identifier",
"fooEdge": {
"cursor": null,
"node": {
"id": "base-64-encoded-tuple",
"bar": "baz"
}
}
}
}
}
The cursor field should return a valid cursor.
{
"data": {
"updateFoo": {
"clientMutationId": "base-64-encoded-identifier",
"fooEdge": {
- "cursor": null,
+ "cursor": "base-64-encoded-cursor",
"node": {
"id": "base-64-encoded-tuple",
"bar": "baz"
}
}
}
}
}
This also affects PostgreSQL 9.6-style tables:
CREATE TABLE foo (
id serial PRIMARY KEY,
bar text NOT NULL
);
temporary workaround using rowId
mutation updateFooMutation($input: UpdateFooInput!, $rowId: Int!) {
updateFoo(input: $input) {
clientMutationId
query {
allFoos(condition: {rowId: $rowId}) {
edges {
cursor
node {
id
bar
}
}
}
}
}
}
Looking into this now.
So turns out this was an issue in v3 also; so while trying to adhere to the v3 test suite I didn't notice the omission.
4 hours of coding later I've fixed it; that was a lot harder than I anticipated! 😅