Hi,
I found a strange behaviour with the autoaugmented merge mutation.
For example: There is a Event and I want to add different results.
After a while the Event accours again with different results.
So I want the field "Time" to be the primary Key in this case.
type Event {
Time: DateTime!
User: String!
Results: [Result]
}
type Result {
Text: String!
}
In Playground:
mutation MergeExample($user: String!, $time: _Neo4jDateTimeInput!) {
MergeEvent(User: $user, Time: $time) {
User
Time {
formatted
}
}
}
Query variables:
{
"user": "UserName",
"time": {"formatted":"2020-01-30T11:00:00+01:00"}
}
Then I get this error message:
{
"errors": [
{
"message": "Invalid input 'H': expected 'i/I' (line 1, column 26 (offset: 25))\n\"MERGE (`event`:`Event`) WHERE `event`.Time = datetime($params.Time.formatted) \"\n ^",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"MergeEvent"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"errors": [
{
"message": "Invalid input 'H': expected 'i/I' (line 1, column 26 (offset: 25))\n\"MERGE (`event`:`Event`) WHERE `event`.Time = datetime($params.Time.formatted) \"\n ^",
"locations": [],
"path": [
"MergeEvent"
]
}
],
"stacktrace": [
"Error: Invalid input 'H': expected 'i/I' (line 1, column 26 (offset: 25))",
"\"MERGE (`event`:`Event`) WHERE `event`.Time = datetime($params.Time.formatted) \"",
" ^",
" at new CombinedError (/home/exampleUser/graphql/node_modules/graphql-tools/src/stitching/errors.ts:90:5)",
" at Object.checkResultAndHandleErrors (/home/exampleUser/graphql/node_modules/graphql-tools/src/stitching/errors.ts:111:11)",
" at CheckResultAndHandleErrors.transformResult (/home/exampleUser/graphql/node_modules/graphql-tools/src/transforms/CheckResultAndHandleErrors.ts:15:12)",
" at /home/exampleUser/graphql/node_modules/graphql-tools/src/transforms/transforms.ts:37:45",
" at Array.reduce (<anonymous>)",
" at applyResultTransforms (/home/exampleUser/graphql/node_modules/graphql-tools/src/transforms/transforms.ts:35:21)",
" at /home/exampleUser/graphql/node_modules/graphql-tools/src/stitching/delegateToSchema.ts:104:12",
" at step (/home/exampleUser/graphql/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:32:23)",
" at Object.next (/home/exampleUser/graphql/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:13:53)",
" at fulfilled (/home/exampleUser/graphql/node_modules/graphql-tools/dist/stitching/delegateToSchema.js:4:58)",
" at <anonymous>",
" at process._tickDomainCallback (internal/process/next_tick.js:228:7)"
]
}
}
}
],
"data": {
"MergeEvent": null
}
}

So far so bad. Now to the very strange part:
When I change the order of the fields Time and User in my typedef to:
type Event {
User: String!
Time: DateTime!
Results: [Result]
}
The above mutation works like a charme.
{
"data": {
"MergeEvent": {
"User": "UserName",
"Time": {
"formatted": "2020-01-30T11:00:00+01:00"
}
}
}
}

Also a result of this is, that the User is now the primary Key. This means there will be only one Event per User in my Neo4J database.
Also strange is that the required attribute (Time! and User!) of the typedef wont get passed on to the MergeEvent mutation...
I ran into a similar issue and discovered that in order for my desired arguments to be present for the autogenerated mutations, I have to reorder my schema.
I'm considering forking the repo and creating functionality for a directive '@mutationArgument' that forces a field to be an argument for autogenerated mutations. Although I have no idea what the code that does that looks like at this time...
Currently I'm running into an issue where my merge mutations are useless because they require the autogenerated ID of the target node lol... So if I want to check if a node already exists, I have to query.
If I'm missing something, I'd love to hear about it! If you think it's a good idea for me to fork and create this feature, lmk.
@inf3rnus Have you considered defining manual queries?
Ideally each type has an ID field which is then used as the "primary key" field for mutations. The current logic is to check for ID!, ID, then the first non-nullable field.
A @unique directive would help clarify the desired field to use for the "primary key" - perhaps we could make it optional to avoid any breaking changes.
Regardless though, DateTime fields should be excluded from the primary key choices.
We've now added @id, and @unique, @constraint directives to explicitly select the "primary key" field. However, temporal and spatial type fields cannot be used for these "primary key" fields, instead a unique ID value should be used.
Most helpful comment
We've now added
@id, and@unique,@constraintdirectives to explicitly select the "primary key" field. However, temporal and spatial type fields cannot be used for these "primary key" fields, instead a unique ID value should be used.