You are looking at the docs for an older version of Dgraph (v21.03). The latest version is v23.1.
Ask a Question

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.