You are looking at the docs for the unreleased master branch of Dgraph. The latest version is v21.03.
Report Issue Edit Page

External IDs

Dgraph’s input language, RDF, also supports triples of the form <a_fixed_identifier> <predicate> literal/node and variants on this, where the label a_fixed_identifier is intended as a unique identifier for a node. For example, mixing identifiers, the movie database identifiers and blank nodes:

_:userA <> <> .
_:userA <dgraph.type> "Person" .
_:userA <> "FirstName LastName" .
<> <> <> .
<> <> "Robin Wright" .

As Dgraph doesn’t natively support such external IDs as node identifiers. Instead, external IDs can be stored as properties of a node with an xid edge. For example, from the above, the predicate names are valid in Dgraph, but the node identified with <> could be identified in Dgraph with a UID, say 0x123, and an edge

<0x123> <xid> "" .
<0x123> <dgraph.type> "ExternalType" .

While Robin Wright might get UID 0x321 and triples

<0x321> <xid> "" .
<0x321> <> <0x123> .
<0x321> <> "Robin Wright" .
<0x321> <dgraph.type> "Person" .

An appropriate schema might be as follows.

xid: string @index(exact) .
<>: [uid] @reverse .

Query Example: All people.

  var(func: eq(xid, "")) {
    allPeople as <~>

  q(func: uid(allPeople)) {

Query Example: Robin Wright by external ID.

  robin(func: eq(xid, "")) {
    expand(_all_) { expand(_all_) }

Note xid edges are not added automatically in mutations. In general it is a user’s responsibility to check for existing xid's and add nodes and xid edges if necessary. Dgraph leaves all checking of uniqueness of such xid's to external processes.
Continue the conversation on Discuss.