Assign UIDs in Slash GraphQL

Users Dgraph Cloud
1

I’m trying out Slash GraphQL but don’t currently have any intention of using the GraphQL portion of it. I am using the Go dgo client and DQL.

My test data uses pre-assigned UIDs so that my queries can be deterministic. The data is “named-spaced” by UID number to keep things organized, which leads to some large UIDs, going up to 0x99999. It doesn’t look like the /assign endpoint is supported in Slash GraphQL. Can someone confirm this for me? And if that is correct, are there any plans to support it?

2

pinging @gja

3

Any update on whether there are plans to support this?

5

Hello, thanks for the question. We are still debating how we will handle this, and the impact on multi tenancy, where uids are shared between tenants.

I think we’d be able to expose this endpoint for dedicated dgraph cloud instances. Let me know if this is something you would like to explore.

6

Correct me if I am wrong here - but I feel like the zero could handle having a different UID lease per tenant, it doesn’t do much with it other than reach quorum with other zeros about that number and report it back to the alpha that asked for it.

Since the storage is handled by predicate and not uid, it doesn’t matter if a uid is shared between tenants, you wouldn’t be able to select any other tenant’s predicates from that UID.

Edit: sorry - speaking in the world of the upcoming multi-tenancy of course.

7

There is a hack way of leasing UIDs. A simple mutation with empty data.

e.g:

{
   set  {
    _:Lease1 <dgraph.type> "Object" .
    _:Lease2 <dgraph.type> "Object" .
    _:Lease3 <dgraph.type> "Object" .
    _:Lease4 <dgraph.type> "Object" .
    _:Lease5 <dgraph.type> "Object" .
    _:Lease6 <dgraph.type> "Object" .
    _:Lease7 <dgraph.type> "Object" .
   }
}

And then you can use a method to extract the UIDs.

8

As of now, we don’t plan to expose the /assign endpoint in Slash. The reason being, the UID counter is shared by tenants in multi-tenancy. A malicious user can ask for 2^64 UIDs causing the whole cluster to run out of UIDs.

Other than this, same UID can be used by multiple tenants.

Suppose on namespace-1 a user does this mutation

<0x1> <name> "alice" . 
<0x1> <age> 15 .

and then on namespace-2 a user does similar mutation

<0x1> <name> "bob" .
<0x1> <age> 12 .

We don’t prevent user of namespace-2 from using the same UID. It is just that user of namespace 1 will see the node <0x1> as:

<0x1> ----name--- <alice>
   |
   |____ age ____ 15

while the user of namespace-2 will see it as,

<0x1> ----name--- <bob>
   |
   |____ age ____ 12

while actually it will have 4 edges, something like this:

<0x1> ----(2name)--- <bob>
   |----(1name)--- <alice>
   |----(1age)--- 15
   |____ (2age) ____ 12

For your use case, you can assume that all the UIDs are owned by you.

1 Like
9

Thanks for the feedback. This likely won’t prevent me from using Slash, but it will prevent me from doing testing there for the time being