Version v21.03.1
Part of my migration strategy involves assigning uids to a fresh cluster (zero/assign?what=uids&num=50000) and then RDF mutate a number of predicates. This works fine.
However when new types are created they can share uids that were assigned in the migration. In other words I can getFoo(id: "0x2717") and getBar(id: "0x2717") with no errors.
My question is: is this a problem? Why aren’t newly generated UIDs greater than the mutation ids that were inserted?
Is that intentional?
I don’t get this question. The mutations using Blank Nodes will create new UIDs after the range you have already leased. If you are not using Blank nodes, it is up to you to control this.
Is that intentional
Nope, after the RDF mutation I’m just mutating the graph using GraphQL addXXX endpoints.
I don’t get this question. The mutations using Blank Nodes will create new UIDs after the range you have already leased. If you are not using Blank nodes, it is up to you to control this.
So the 40,000+ predicates I’m RDF mutating during my migration have UIDs assigned (not using blank nodes, hence the need to allocate those UIDs). Following that, all subsequent mutations use the GraphQL add endpoints. My expectation was that types created following my migration (in which I allocate 50,000 UIDs) would have UIDs starting at 0xC351 (50,001). This does not seem to be the case.
Should I create a properly documented issue?
Please, a way to reproduce would help a lot.
What you said feels odd.
I can’t seem to reproduce. I’ll keep an eye out for the problem again. It maybe some timing issue where I’m mixing fixed UIDs with GraphQL mutations.
But I guess back to my original question… I do have a graph that has the same UID for two different types. Is this an issue for dgraph?
Not for Dgraph itself, but for you. Cuz they have the same UID and for your schema design they should be two different entities, right? Any move you do, you can end up deleting some predicate by accident.