UID Predicate with max count = 1

Users
1

Hi all,

Similar to non-list scalar types, which are overwritten when a new set item is written for the same subject and predicate, I want to have schema entries of type uid which can have only one occurrence per subject node. Currently, if I want to update the Namespace attribute for a node, I have to call dgraph twice:

First call:

mutation { delete {
<a> <Namespace> * .
}}

Second call:

mutation { set {
<a> <Namespace> "New Namespace" .
}}

Instead, I would like to define in the schema that the previous triple should be replaced by the new one in any set mutation so that the first call is unnecessary.

Am I maybe misunderstanding some feature that already does this? Also, I would put the delete {} and set {} blocks within the same mutation, but I would need them to run in series. I think if I put both blocks in the same mutation, as of v0.8.3, they will run in parallel?

2

I have a similar problem, I guess this should be something like a bug because in theory you should be able to join this in a single query, but it seems the order of execution is not the order in which you provide the commands:

SCHEMA:

mutation {
    schema {
        name: string @index(exact,term) @count .
        Namespace: uid @count @reverse .
    }
}

CREATE NODES:

mutation {
  set {
    _:node1 <name> "node1" .
    _:node1 <Namespace> _:node3 .
    
    _:node2 <name> "node2" .
    _:node2 <Namespace> _:node3 .
    
    _:node3 <name> "node3" .
    _:node3 <Namespace> _:node1 .
  }
}

OVERRIDE RELATIONS:

{
  node1 as var(func:eq(name, "node1"))
  node2 as var(func:eq(name, "node2"))
}
  
mutation {
  delete {
    uid(node1) <Namespace> * .
  }
  
  set {
    uid(node1) <Namespace> uid(node2) .
  }
}

This WILL NOT WORK, because the “delete” statement will be always executed at the end of the query, no matters if you put it first in the command sequence.

3

Seems like a valid use case.

I think we could achieve this via an instruction in the schema that a particular predicate must only have one outgoing edge. Is that what you’re looking for? If so, please feel free to file a Github issue, and we’ll solve for this in v0.9 series.

Update: Looks like an issue already exists.

4

Yes, this solution would be ideal. Thanks!