Support UUIDs in Dgraph

[oharlem]

Hi guys,

I'm considering Dgraph as a graph-handling addition to the current primary db and we already have ids (UUID v4) for all objects, so naturally I would like to have the same keys in DGraph and looks like I won't need uids at all.
My concern is a statement that you do not recommend using external ids.
I believe we will have a certain performance hit because not using dgraph's uids and (maybe) having to lookup on a non-primary key, but frankly not sure how xids work - could you please elaborate on any issue I may have looking up dgraph objects by my own ids instead of uids?

Thank you!
Dennis

P.S.
I believe this may be categorized as "documentation" request.

[manishrjain]

Hey @mpmlj ,

Yeah, instead of using UUIDs as external id, you can have an extra edge, which stores UUID, and index it. That way, you can still search for nodes via UUID, but Dgraph would also allocate its own IDs which would be unique, without any concerns about collisions.

For e.g., You can do this:

mutation { set {
  _:node <uuid> "123e4567-e89b-12d3-a456-426655440000" .
}}

Index it using a schema which contains this line:

uuid: string @index(exact)

And then query it like so:

{
  node(eq(uuid, "123e4567-e89b-12d3-a456-426655440000")) {
    stuff
  }
}

Does this help? We'll add this to documentation as well.

[AndreSteenbergen]

I am using this method as well right now. It works, there is only one real issue this way. writes are not idempotent anymore. Running this twice result in 1 write,

mutation{
set{
<0x01> <objectId> "UUID" .
}
}

But running this twice, will result in two nodes, each having an edge UUID

mutation{
set{
_:myId <objectId> "UUID" .
}
}

or we need variables mixed (is this possible?) .....

{
  var A (node(eq(uuid, "123e4567-e89b-12d3-a456-426655440000")) {
    stuff
  })
}
mutation {
set {
<id(A)> <objectId> "UUID"
}
}

[manishrjain]

We do need a solution to this problem. What @AndreSteenbergen, you're proposing is in the right direction, but not currently possible the way we do mutations (they happen before queries). Also, any solution that we implement, won't be transactional. Needs more thought.

Here's another thought: If all your ids are UUID, then you can safely send mutations with them as XIDs, without any worries about collisions (unique strings will with very high probability convert to unique int64s). If you then allocate new entities in Dgraph, they'd know about these allocated ids (we keep track of used ids) , and allocate new ones.

[AndreSteenbergen]

OK I am actually doing this, because of the same statements @mpmlj refers to, not to depend on xid

[AndreSteenbergen]

I am event sourcing my app, I only have UUID's in the system

[foobatman]

+1 to what @AndreSteenbergen is suggesting, I am also looking for something similar where I can find an existing node in graph and create new edge / predicate from it to new node inside mutation block.

[manishrjain]

This is a frequently requested feature, we'll build it with priority.