Add id manually while using GraphQL

[spinelsun (Or Chen)]

Hi,

Assuimng my scheme is:

type Person {
    id: ID!
    name: String @search(by: [hash])
    friends: [Person] @hasInverse(field: friends)
}

Is there a way to define IDs to objects in GraphQL like the following in graphql±:

{
    "set":[
        {
            "uid": "_:p1",
            "dgraph.type": "Person",
            "Person.name": "John",
            "Person.friends": [
                {
                    "uid": "_:p2"
                },
                {
                    "uid": "_:p3"
                }
            ]
        },
        {
            "uid":"_:p2",
            "dgraph.type":"Person",
            "Person.name": "Doe"
        },
        {
            "uid": "_:p3",
            "dgraph.type": "Person",
            "Person.name": "Jane",
            "Person.friends": [
                {
                    "uid":"_:p1"
                }
            ]
        }
    ]
}

Also, what is the right way to insert the following data using GraphQL and the scheme I supplied above?
Notice that the ‘friends’ field has the @hasInverse (or @revers in DQL)
My guess was the one below but it doesn’t has the same result:

mutation {
  addPerson(
    input: [
      {
        name: "Or"
        friends: [
          { name: "Michal", friends: [{ name: "Or" }] }
          { name: "Elior" }
        ]
      }
    ]
  ) {
    person {
      name
      friends {
        name
      }
    }
  }
}

Thanks

[abhijit-kar (Abhijit Kar ツ)]

To set custom id, you can use @id directive.

type Person {
  id: String! @id
}

Refer: Documentation on @Id

[spinelsun (Or Chen)]

Thanks, I meant how can I add an id in the data not in the scheme.
In DQL for example it is possible to do this:

{
            "uid": "_:p1",
            "dgraph.type": "Person",
            "Person.name": "John",

where _:p1 is being translated into a uid

[amaster507 (Anthony Master)]

There is no way to to do this with your schema in graphql generated mutations in a single mutation. You will either need to use xids but that can cause extra work on the front end needing to generate uniqie ids of some sort. If creating two people at once and trying to link them as friends, you may need to do it with a custom DQL which has its draw backs as well.

@spinelsun

My guess was the one below but it doesn’t has the same result:

This doesn’t have the results expected because it created two seaparate ‘Or’ people. The generated mutation is not able to know that the first ‘Or’ is the same as the second ‘Or’ because the name field is not unique constraint.

However, having the hasInverse. You only need to make the link from one to the other and the reverse will be made automatically.

I will look at this a little closer later on my desktop to get the whole concept and maybe a better answer

[spinelsun (Or Chen)]

Thank you.
I tried some other forms of the data and I tuckled something a little bit strange:
That’s the data:

mutation {
  addPerson(
    input: [
      {
        name: "Or"
        friends: [
          { name: "Michal", friends: [{ name: "Justin" }] }
          { name: "Elior" }
        ]
      }
    ]
  ) {
    person {
      name
      friends {
        name
      }
    }
  }
}

That’s my query:

query{
  queryPerson{
    id
    name
    friends{
      name
    }
  }
}

And this is the result

{
  "data": {
    "queryPerson": [
      {
        "id": "0x9c62",
        "name": "Elior",
        "friends": [
          {
            "name": "Or"
          }
        ]
      },
      {
        "id": "0x9c63",
        "name": "Justin",
        "friends": [
          {
            "name": "Michal"
          }
        ]
      },
      {
        "id": "0x9c64",
        "name": "Michal",
        "friends": [
          {
            "name": "Justin"
          }
        ]
      },
      {
        "id": "0x9c65",
        "name": "Or",
        "friends": [
          {
            "name": "Elior"
          },
          {
            "name": "Michal"
          }
        ]
      }
    ]
  }
}

Michal doesn’t have the revers connection with Or.
Can you please explain why?

[chewxy]

@MichelDiz any ideas?

[anand (Anand Chandrashekar)]

Graphql requires specification of the traversals, and the following query will get you the other edges as well. Please see if this helps.

query{
  queryPerson{
    id
    name
    friends{
      name
      friends{
        name
      }
    }
  }
}

Response:

{
  "data": {
    "queryPerson": [
      {
        "id": "0x2",
        "name": "Or",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Or"
              }
            ]
          }
        ]
      },
      {
        "id": "0x3",
        "name": "Michal",
        "friends": [
          {
            "name": "Or",
            "friends": [
              {
                "name": "Michal"
              }
            ]
          }
        ]
      },
      {
        "id": "0x4",
        "name": "Or",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Or"
              }
            ]
          },
          {
            "name": "Elior",
            "friends": [
              {
                "name": "Or"
              }
            ]
          }
        ]
      },
      {
        "id": "0x5",
        "name": "Elior",
        "friends": [
          {
            "name": "Or",
            "friends": [
              {
                "name": "Michal"
              },
              {
                "name": "Elior"
              }
            ]
          }
        ]
      }
    ]
  },
  "extensions": {
    "touched_uids": 32
  }
}

[spinelsun (Or Chen)]

Nope
The result of the query you suggest is:

{
  "data": {
    "queryPerson": [
      {
        "id": "0xc356",
        "name": "Or",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Justin"
              }
            ]
          },
          {
            "name": "Elior",
            "friends": [
              {
                "name": "Or"
              }
            ]
          }
        ]
      },
      {
        "id": "0xc357",
        "name": "Justin",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Justin"
              }
            ]
          }
        ]
      },
      {
        "id": "0xc358",
        "name": "Michal",
        "friends": [
          {
            "name": "Justin",
            "friends": [
              {
                "name": "Michal"
              }
            ]
          }
        ]
      },
      {
        "id": "0xc359",
        "name": "Elior",
        "friends": [
          {
            "name": "Or",
            "friends": [
              {
                "name": "Michal"
              },
              {
                "name": "Elior"
              }
            ]
          }
        ]
      }
    ]
  }
}

[MichelDiz]

I’m a bit confused, do you wanna have the “uid” predicate itself on your GraphQL mutation?

The @id directive, as far as I know, is a “custom” way to add a reference/identifier in GraphQL. e.g. username: String! @id this would make “username” unique. That’s similar to the DQL identifier. But the advantage is that your mutation will always run in the same node no matter what. It is almost the same behavior we could do with the upsert block. But I think, we should use the update mutation instead of creating mutation. That’s a usual pattern in GraphQL.

I have experience with GraphQL, but I haven’t stopped to focus on Dgraph’s GraphQL yet, I have used it, but not deeply. It has features that don’t come by default in GraphQL Specs. So, I’m taking it for granted, based only on my old experience with GraphQL. Just the Dgraph’s features I can’t be 100%, by reading the docs, seems logical what I’m stating.

I can be wrong, correct me if so.

Cheers.

[amaster507 (Anthony Master)]

@spinelsun, It looks like you found a bug:

@spinelsun

Nope
The result of the query you suggest is: […]

If you do this mutation:

@spinelsun

mutation {
  addPerson(
    input: [
      {
        name: "Or"
        friends: [
          { name: "Michal", friends: [{ name: "Justin" }] }
          { name: "Elior" }
        ]
      }
    ]
  ) {
    person {
      name
      friends {
        name
      }
    }
  }
}

On this schema:

@spinelsun

type Person {
    id: ID!
    name: String @search(by: [hash])
    friends: [Person] @hasInverse(field: friends)
}

And then run this query:

@anand

query{
  queryPerson{
    id
    name
    friends{
      name
      friends{
        name
      }
    }
  }
}

It should have produced the results:

Or <-> Michal
Michal <-> Justin
Or <-> Elior

But if you look at the results we will find:

Or -> Michal
Michal <-> Justin
Or <-> Elior

@MichelDiz, @Pawan I think we have a bug here where the person “Or” is only linked to Michal with a one-way link instead of a two way as it should have been done.

Just tested on Slash: v20.07.1-rc1-12-gbfa6277f

And here is the complete steps to reproduce:

  addPerson(
    input: [
      {
        name: "Or"
        friends: [
          { name: "Michal", friends: [{ name: "Justin" }] }
          { name: "Elior" }
        ]
      }
    ]
  ) {
    person {
      name
      friends {
        name
      }
    }
  }
}
query ReadData {
  queryPerson{
    id
    name
    friends{
      name
      friends{
        name
      }
    }
  }
}
mutation ResetData {
  deletePerson (filter: {}) { numUids }
}

AddData:

{
  "data": {
    "addPerson": {
      "person": [
        {
          "name": "Or",
          "friends": [
            {
              "name": "Michal"
            },
            {
              "name": "Elior"
            }
          ]
        }
      ]
    }
  },
  "extensions": {
    "touched_uids": 8,
    "tracing": {
      "version": 1,
      "startTime": "2020-09-07T14:47:21.526305936Z",
      "endTime": "2020-09-07T14:47:21.538247035Z",
      "duration": 11941104,
      "execution": {
        "resolvers": [
          {
            "path": [
              "addPerson"
            ],
            "parentType": "Mutation",
            "fieldName": "addPerson",
            "returnType": "AddPersonPayload",
            "startOffset": 128337,
            "duration": 11795506,
            "dgraph": [
              {
                "label": "mutation",
                "startOffset": 208815,
                "duration": 4902737
              },
              {
                "label": "query",
                "startOffset": 7524027,
                "duration": 4364265
              }
            ]
          }
        ]
      }
    },
    "queryCost": 1
  }
}

ReadData:

{
  "data": {
    "queryPerson": [
      {
        "id": "0x7",
        "name": "Justin",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Justin"
              }
            ]
          }
        ]
      },
      {
        "id": "0x8",
        "name": "Michal",
        "friends": [
          {
            "name": "Justin",
            "friends": [
              {
                "name": "Michal"
              }
            ]
          }
        ]
      },
      {
        "id": "0x9",
        "name": "Or",
        "friends": [
          {
            "name": "Michal",
            "friends": [
              {
                "name": "Justin"
              }
            ]
          },
          {
            "name": "Elior",
            "friends": [
              {
                "name": "Or"
              }
            ]
          }
        ]
      },
      {
        "id": "0xa",
        "name": "Elior",
        "friends": [
          {
            "name": "Or",
            "friends": [
              {
                "name": "Michal"
              },
              {
                "name": "Elior"
              }
            ]
          }
        ]
      }
    ]
  },
  "extensions": {
    "touched_uids": 32,
    "tracing": {
      "version": 1,
      "startTime": "2020-09-07T14:48:46.961435556Z",
      "endTime": "2020-09-07T14:48:46.96342668Z",
      "duration": 1991133,
      "execution": {
        "resolvers": [
          {
            "path": [
              "queryPerson"
            ],
            "parentType": "Query",
            "fieldName": "queryPerson",
            "returnType": "[Person]",
            "startOffset": 146977,
            "duration": 1800338,
            "dgraph": [
              {
                "label": "query",
                "startOffset": 195516,
                "duration": 1678721
              }
            ]
          }
        ]
      }
    },
    "queryCost": 1
  }
}

ResetData:

{
  "data": {
    "deletePerson": {
      "numUids": 4
    }
  },
  "extensions": {
    "touched_uids": 8,
    "tracing": {
      "version": 1,
      "startTime": "2020-09-07T14:49:59.435734133Z",
      "endTime": "2020-09-07T14:49:59.444221073Z",
      "duration": 8486954,
      "execution": {
        "resolvers": [
          {
            "path": [
              "deletePerson"
            ],
            "parentType": "Mutation",
            "fieldName": "deletePerson",
            "returnType": "DeletePersonPayload",
            "startOffset": 135600,
            "duration": 8331000,
            "dgraph": [
              {
                "label": "mutation",
                "startOffset": 180332,
                "duration": 5844148
              },
              {
                "label": "query",
                "startOffset": 8447288,
                "duration": 6132
              }
            ]
          }
        ]
      }
    },
    "queryCost": 1
  }
}

[anand (Anand Chandrashekar)]

Hi @spinelsun, looks like I used a different mutation. I am seeing a similar result to what you are seeing too and it might be a bug.

[amaster507 (Anthony Master)]

@MichelDiz

I’m a bit confused, do you wanna have the “uid” predicate itself on your GraphQL mutation?

The @id directive, as far as I know, is a “custom” way to add a reference/identifier in GraphQL. e.g. username: String! @id this would make “username” unique. That’s similar to the DQL identifier. But the advantage is that your mutation will always run in the same node no matter what. It is almost the same behavior we could do with the upsert block.

I think the intended concept is to have a similar experience to using blank nodes in Dgraph in the add mutation. The OP does not want to use custom IDs but rather use Dgraph’s IDs but just have a way to define links between them in a single addMutation. To expand on the example for better proof of concept lets say we wanted to create these new people as friends:

Or <-> Michal
Or <-> Justin
Or <-> Elior
Michal <-> Justin

This becomes complicated with a single mutation because you have to stop and think of where to begin the mutation from and how to nest everything listing each item only once to make the desired links. There is actually no way to nest the above making the desired links in a single addMutation without listing at least one of the Persons twice. Here is different ways I tried to arrange them:

Or.friends: [
  Michal.friends: [
    Justin
  ]
  Justin # listed 2x
  Elior
]

Justin.friends: [
  Or.friends: [
    Elior
    Michal
  ]
  Michal # listed 2x
]

Michal.friends: [
  Justin
  Or.friends: [
    Elior
    Justin # listed 2x
  ]
]

Elior.friends: [
  Or.friends: [
    Michal.friends: [
      Justin
    ]
    Justin # listed 2x
  ]
]

It is just impossible to do in a single mutation without blank nodes (not currently capable) or xids (not wanted, need to have capability of multiple people with the name Justin for example, and don’t want to generate unique UIDs across every UI).

@MichelDiz

But I think, we should use the update mutation instead of creating mutation. That’s a usual pattern in GraphQL.

How can we use the update mutation if none of the data we are adding already exists? What we would have to do: Add the people in a addMutation and then capture the ids, link the ids back to the created people, and make a second trip with a updateMutation to create the links. a good graphDB API (added API, because Dgraph supports it, just the generated graphql endpoint does not), should be able to support this without separating the logic into two round trips.

---

My personal experience hit this road block very early on. Understanding it as just a limitation of the graphql endpoint, I discovered early how to use DQL to insert data using blank nodes. If this was capable to use blank nodes with the graphql endpoint, it would help me as well.

I want to enable users to import data. Some of these imports will contain deep nested relationships like this illustration. I will have to open some DQL, RDF door to do these imports. This could lead to other issues where now in order to make the nested relationships I loose the functionality of the hasInverse logic in the API layer and must manually create the RDF for all of the reverse edges.

Does this help clear up what the OP is wanting and how it could be useful?

[MichelDiz]

I’ll summarize the concepts here.

@spinelsun

Is there a way to define IDs to objects in GraphQL like the following in graphql±:

This "uid": "_:p1" isn’t an UID or ID or Unique identifier. This is a blank node, it is used in the transaction context to ask the Zero group UIDs for that entity. So, totally not possible in the GraphQL context, cuz Blank Nodes are DQL only related.

@spinelsun

Also, what is the right way to insert the following data using GraphQL and the scheme I supplied above?

You should follow the Docs generated by GraphQL itself. When you send a Schema, GraphQL does the documentation about the API right out of the box. You should read it all the time, every change you do to your Schema.

@spinelsun

Notice that the ‘friends’ field has the @hasInverse (or @revers in DQL)

Those are different things. GraphQL doesn’t use the Reverse index.

@spinelsun

My guess was the one below but it doesn’t has the same result:

What result exactly do you expect?

@spinelsun

Michal doesn’t have the revers connection with Or.
Can you please explain why?

I think that the reason is that “Or” is a parent, and your query asks for Childs. So “Or” isn’t a Child of “Michal”. The inverse doesn’t mean that it will appear for you anyway, you need a way to query inverse. In DQL we use the “tilde” notation. That means, <~friend> will return the inverse ones. You can’t mix the inverse and the real direction on a query result. It could potentially break applications and confuses the user.

@amaster507

It looks like you found a bug:

nah, feels like a misunderstanding tho. See the comment above.

@amaster507

I think we have a bug here where the person “Or” is only linked to Michal with a one-way link instead of a two way as it should have been done.

BTW, do we have a <~friend> notation in GraphQL? I think that the inverse one is used for other proposes. Not to show inversed edges, just to use them. I can be wrong tho.

@amaster507

I think the intended concept is to have a similar experience to using blank nodes in Dgraph in the add mutation.

Not possible for now I guess, would be interesting to have it at GraphQL mutation level. But is possible to do with custom DQL tho.

@amaster507

The OP does not want to use custom IDs but rather use Dgraph’s IDs but just have a way to define links between them in a single addMutation.

Just the fact to have edges you are creating “fixed” relations. Blank nodes have other propose.

@amaster507

This becomes complicated with a single mutation because you have to stop and think of where to begin the mutation from and how to nest everything listing each item only once to make the desired links.

Hum, by reading this feels like blank nodes in GraphQL seem useful. Cuz you could send big chunks of GraphQL objects in the mutation input, and not relate them via edges. e.g.

Instead of

(
    input: [
   {
      name: "lucas",
      friendOf: [
         {
            name: "Jorge",
            friendOf: [
               {
                    name: "lucas"
               }
            ]
         }
      ]
   }
  )

It could be like:

addPerson(
    input: [
 {
      uid: "_:Lucas",
      name: "lucas",
      friendOf: [
         {
            uid: "_:Jorge"
         }
      ]
   },
   {
      uid: "_:Jorge",
      name: "lucas",
      friendOf: [
         {
            uid: "_:Lucas"
         }
      ]
   }
    ]
  )

That’s a view of the organization at transaction level. But the @id directive could do the same thing.

@amaster507

How can we use the update mutation if none of the data we are adding already exists?

One of the entities should exist, and (using the @id directive) Dgraph would create the other one. You just need the root and the other will be linked via custom id.

I have tested it with update mutation. It works, but not as I would like to do.

e.g

mutation {
  updatePerson(
    input: { 
      filter: {
        name: { eq: "Test" }
      }
      set: {
        friends: [
          { name: "Lucas" }, { name: "Deng" }
          { name: "Phillip" }, { name: "Lucas 2" }
        ]
      }
    }
  ) {
    person {
      name
      friends {
        name
      }
    }
  }
}

This mutation above will search for the “Test” entity. And link or create the others.

In my opinion, this update should have a better method. e.g

  addPerson(
    input: [
      {
        byID: "Test"
        friends: [
          { name: "Lucas", friends: [{ name: "Deng" }] }
          { name: "Phillip" }
        ]
      }
    ]
  )

The byID: "..." method would be more clean and direct.

@amaster507

Does this help clear up what the OP is wanting and how it could be useful?

I agree with the Blank node usage could potentially make things easy. But GraphQL is about simple mutations. Your application won’t send huge mutations. In general, who uses GraphQL, won’t add like 10 friends in a single batch. Your front-end doesn’t have this concept of bulk. You could create something like a queue, but feels odd. Front-end applications will do each new relation a single mutation of two edges, not 20, you know?

If you wanna bulk data into Dgraph, you should do it via Liveload. Not GraphQL mutation.

Cheers.

[amaster507 (Anthony Master)]

@MichelDiz

If you wanna bulk data into Dgraph, you should do it via Liveload. Not GraphQL mutation.

Bahumbug, lol. And this is where we differ. I want to keep the logical restrictions imposed by the graphql endpoint that the liveloader does not honor. We are not talking about importing GBs of data, but rather a users Contact lists from an excel sheet of ~100 contacts, which could contain (as we would have to parse in a script) a link to contacts family, and employer, and friends. These would all be imported at once, and hopefully by a mutation in graphql

As we start to integrate with other graphDB services I am sure we will start to get data going both ways in JSON format and we would want to make the mutations again with graphql.

Anyways, I think this is stepping away from the OP, but just my feedback.

@MichelDiz

@spinelsun

Michal doesn’t have the revers connection with Or.

Can you please explain why?

I think that the reason is that “Or” is a parent, and your query asks for Childs. So “Or” isn’t a Child of “Michal”. The inverse doesn’t mean that it will appear for you anyway, you need a way to query inverse. In DQL we use the “tilde” notation. That means, <~friend> will return the inverse ones. You can’t mix the inverse and the real direction on a query result. It could potentially break applications and confuses the user.

@amaster507

It looks like you found a bug:

nah, feels like a misunderstanding tho. See the comment above.

@amaster507

I think we have a bug here where the person “Or” is only linked to Michal with a one-way link instead of a two way as it should have been done.

BTW, do we have a <~friend> notation in GraphQL? I think that the inverse one is used for other proposes. Not to show inversed edges, just to use them. I can be wrong tho.

Is my understanding here correct:

@hasInverse GraphQL to DQL mapping

This is done purposefully. @hasInverse is not the equivalent to adding the @reverse directive in DQL. On the graphql schema, the @hasInverse directive creates logic in the resolvers to add/update/delete the inverse edge of the specified type. There is more to the underlying reasoning behind this but overall it is to allow for better type notatation predicate control. In DQL a single predicate can be applied between two types, but in GQL, if a Post Type has an author predicate and a Author Type …

if so, then it is a bug. I think @pawan agrees that it is a bug, as he added the bug tag.

[pawan (Pawan Rawal)]

Yeah this looks like a bug as pointed out by @amaster507. I’ll have a deeper look tomorrow and confirm of the cause.

@MichelDiz

The inverse doesn’t mean that it will appear for you anyway, you need a way to query inverse. In DQL we use the “tilde” notation. That means, <~friend> will return the inverse ones.

@hasInverse in GraphQL is not implemented using @reverse under the hood. So you don’t need to add the ~ notation to query it. You should be able to query it using the field name.

There is a lot of interesting and useful feedback in this thread which I’ll go through at length this week. Thanks for that!

[MichelDiz]

@pawan

You should be able to query it using the field name.

But how to defer a child from a parent relation? Both will be shown as it was nested?

[pawan (Pawan Rawal)]

Here is a PR with the fix: fix(GraphQL): Fix squashIntoObject so that results are correctly merged by pawanrawal · Pull Request #6416 · dgraph-io/dgraph · GitHub

@MichelDiz

But how to defer a child from a parent relation? Both will be shown as it was nested?

I am not if I understand this, could you give me an example that would help me understand better?

[MichelDiz]

Neither I, I’m assuming that the user and you are saying that @hasInverse and @reverse has the same logic. And the only difference between them is that @hasInverse doesn’t uses the reverse index.

Taking @reverse into consideration. When you use the tilde you are basically asking Dgraph for incoming edges/nodes. Does that works the same on GraphQL or the usage of @hasInverse is totally for other propose?

If @hasInverse has the same goal as @reverse, so @hasInverse should have a way to differentiate the directions.

The point is, I don’t know how @hasInverse works, and feels like the user thinks it is 100% like @reverse. But with a different notation.

Update:

The docs says:

@hasInverse is used to setup up two way edges such that adding a edge in one direction automically adds the one in the inverse direction.

This statement is exactly what @reverse do. But @reverse adds in the same edge in a reversed way. And @hasInverse do it to GraphQL types. But feels like it adds an edge automatically, not a “reverse” as we spect. if so, this should be clear to not confuse users with DQL.

[spinelsun (Or Chen)]

GraphQL supports custom directives.
Maybe it will the best thing to add the @reverse directive to the language and translate it in dgraph internals.
neo4j did something similar by declering the directive @relation which is a great idea by itself.
with the @relation you can specify the direction of the relationship and also properties on the relation (similar to facets in dgraph).
I’m adding a link to the concept here: @relation directive

@MichelDiz

This statement is exactly what @reverse do. But @reverse adds in the same edge in a reversed way. And @hasInverse do it to GraphQL types. But feels like it adds an edge automatically, not a “reverse” as we spect. if so, this should be clear to not confuse users with DQL.

About this, I understand now the delicate difference between the two directives. It is still a bit confusing though. If the docs could contain more concrete examples and explanations on when to use each one of them it would be great.

[MichelDiz]

@spinelsun

If the docs could contain more concrete examples and explanations on when to use each one of them it would be great.

I agree, the docs should add a “reason/goal” for each feature. That way would help to understand the differences easily. Especially when such a feature has homonymous.