I read the doc of it , but can’t understand what it is used for
if it can’t be used in this way:
set {
_:user <dgraph.graphql.xid> "test" .
}
or this way:
query(func:uid(xid)) {
}
and an node with xid can only be queried by func:eq, it is then just a normal predicate, which scenario it is used for ?
@MichelDiz correct me if needed as you are the DQL expert.
According to DQL docs,
xidedges are not added automatically in mutations. In general it is a user’s responsibility to check for existingxid's and add nodes andxidedges if necessary. Dgraph leaves all checking of uniqueness of suchxid's to external processes.
xid then becomes more of an algorithm to achieve a solution than an actual database implementation.
It works just like any normal predicate in Dgraph. There are no special functions to use xid.
Your external processes need to use upserts to correctly use xids.
On a sidenote, Dgraph’s generated GraphQL API has put a lot of emphasis on these external ids and treat them more like first class citizens even though they are still just normal predicates. This is achieved because the GraphQL queries and mutations are rewritten into DQL. The GraphQL API becomes these external processes described in the DQL documentation.
This is an internal predicate. Used internally by Dgraph’s GraphQL feature. Users shouldn’t be touching this. e.g Please hide the internal predicates
This is a query function to UIDs, not XIDs. There’s no XID function tho. XIDs are just references used for external or custom identifiers.
Yes, if a node has a XID, you have to use eq cuz it is just a normal predicate. Those scenarios mentioned above. We also use XIDs in upsert processes in Liveload.
All good. 