# Unique Indexes on predicates

**URL:** <https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964>\
**Category:** Users\
**Created:** [November 17, 2017, 11:38am UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964 "2017-11-17T11:38:12Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![tamethecomplex](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/tamethecomplex/32/496_2.png) [@tamethecomplex](https://discuss.dgraph.io/u/tamethecomplex)\
**Post date:** [November 17, 2017, 11:38am UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/1 "2017-11-17T11:38:12Z")

</div>

Hi Dgraph team,

This is a followup from a couple of posts by @calummoore linked below.

I am working on writing several inbound integrations to dgraph, and it would be extremely helpful to have a ‘unique’ tokenizer on string indexes that would guarantee that only one node in the whole database has the same value for that predicate. @calummoore, hopefully I am accurately representing your original request. Is this something you guys can see implementing in the short term?

> [@Major changes in v0.9](http://discuss.hypermode.com/t/major-changes-in-v0-9/1886/37):
>
> I’m not using it. In the upcoming release, will unique indexes be included as part of transactions, or will we still need to manage that outside of Dgraph? Also, I’m looking to go live with a new app shortly, but it seems like 0.9 will be a fairly major change, so might be worth waiting. Any updated view on when it might be available (no worries if not)?

> [@Transactions in Dgraph](http://discuss.hypermode.com/t/transactions-in-dgraph/1641):
>
> Is there any support for adding transactions to Dgraph? I see the use cases as: financial transactions adding unique indexes (useful for user auth providers) allocating stock to an order / decrementing stock levels time scheduling preventing inconsistent data You could add this by applying conditions that need to pass before applying a mutation - i.e. only apply a mutation if the following assertions are met. mutation { transaction { actor (func: allofterms(name@en, "jones indiana")) …

---

<div class="post-metadata">

**Author:** ![calummoore](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/calummoore/32/614_2.png) [@calummoore](https://discuss.dgraph.io/u/calummoore)\
**Post date:** [November 17, 2017, 11:45am UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/2 "2017-11-17T11:45:19Z")

</div>

Hi

Dgraph now supports transactions! So all of the above can now be done using them.

If you want to assert a unique index, you would:

1. Create a transaction (this is done locally) by the client
2. Send a query (via the transaction) to check if the predicate value already exists
3. If it does, abort. If it doesn’t send a mutation to add the key as part of the transaction.
4. Commit the transaction. Dgraph will abort if the query/mutation is no longer valid.

You can find out how to create a transaction for your given client on the [client docs](https://docs.dgraph.io/clients/).

EDIT: you can read more about transactions here: [Releasing distributed transactions in v0.9 - Dgraph Blog](http://discuss.hypermode.com/t/releasing-distributed-transactions-in-v0-9-dgraph-blog/1962)

---

<div class="post-metadata">

**Author:** ![tamethecomplex](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/tamethecomplex/32/496_2.png) [@tamethecomplex](https://discuss.dgraph.io/u/tamethecomplex)\
**Post date:** [November 17, 2017, 11:56am UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/3 "2017-11-17T11:56:27Z")

</div>

Hi @calummoore, makes sense. I was hoping to have the guarantee of uniqueness without having to write the extra check in #2 above. Do you think this is overkill or would this be a useful feature regardless?

Another reason I can think of that enforced uniqueness would be useful is if there are multiple people developing an app on top of a given instance, and someone creates a bug that fails to check uniqueness before writing. Having this rock-solid uniqueness guarantee at the database level would still be a useful feature to have, IMHO.

---

<div class="post-metadata">

**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\
**Post date:** [November 17, 2017, 8:19pm UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/4 "2017-11-17T20:19:58Z")

</div>

We’ve planned this issue for v0.9:

> <https://github.com/dgraph-io/dgraph/issues/1519>
>
> As posted on the \[community forum\](https://discuss.hypermode.com/t/single-uid-assign…ed-to-predicate/1787):
> 
> It would be useful to be able to assign a \`uid\` to a predicate directly without adding it to a Posting List. For example, I might have a predicate \`teacher\`, where it is only ever possible to have one \`teacher\` at a time. 
> 
> At the moment I would have to do the following to update the predicate, which means 2 round trips and is unnecessarily verbose. 
> 
> \`\`\`
> mutation {
> delete {
> \<0x4\> teacher \* .
> }
> }
> 
> mutation {
> set {
> \<0x4\> teacher \<0x9\> .
> }
> }
> \`\`\`
> 
> Ideally, you would want to be able to specify in the schema that that predicate only accepts a single uid.
> 
> \`\`\`
> mutation {
> schema {
> teacher: uid @unary
> }
> }
> \`\`\`
> 
> It would also have the added benefit of being able to return an object instead of an array when the unary predicate is being queried, as it would know there could only ever be one node/object.

@pawan is assigned to this.

---

<div class="post-metadata">

**Author:** ![tamethecomplex](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/tamethecomplex/32/496_2.png) [@tamethecomplex](https://discuss.dgraph.io/u/tamethecomplex)\
**Post date:** [November 17, 2017, 8:30pm UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/5 "2017-11-17T20:30:41Z")

</div>

Thanks @mrjn, but I’m not sure we’re referring to the same thing. The @urnary predicate seems it would apply to a Node → Predicate → Node relationship where there can be only one such relationship per origin node. But for the “unique index”, I was thinking:

`Node -> Predicate with UIX -> "Unique literal value"`

Where there is a database-wide guarantee that for “Predicate with UIX”, one and only one node has a given “Unique literal value”.

That way if I have ten source systems all sending entities into dgraph and populating “Predicate with UIX” with hypothetically conflicting values, I have a uniqueness guarantee at the database level that can never be violated even if someone messes up by not checking first to see if that value already exists. Basically extending the enforced uniqueness that UID’s have to other predicates as well.

---

<div class="post-metadata">

**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\
**Post date:** [November 17, 2017, 8:49pm UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/6 "2017-11-17T20:49:12Z")

</div>

This is similar to the login system described in the blog post:

> **[Releasing distributed transactions in v0.9 - Dgraph Blog](https://dgraph.io/blog/post/v0.9/)**
>
> It all started with a Github issue.
> At Dgraph, we really care about user feedback. Most of what we’ve built starting January 2017, has been based what our community (that’s you!

```auto
q := fmt.Sprintf(`
    {
        login_attempt(func: eq(email, %q)) {
            checkpwd(pass, %q)
        }
    }
`, email, pass)
resp, err := txn.Query(ctx, q)

```

In this example, we check that the email is unique, by using a hash index on `email` attribute.

That’s the benefit of transactions, such checks are possible completely via client code. If you have multiple people writing to Dgraph, they should all be running this logic transactionally.

I now reckon this is the same response as by @calummoore.

---

<div class="post-metadata">

**Author:** ![tamethecomplex](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/tamethecomplex/32/496_2.png) [@tamethecomplex](https://discuss.dgraph.io/u/tamethecomplex)\
**Post date:** [November 18, 2017, 2:42pm UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/7 "2017-11-18T14:42:22Z")

</div>

Thanks guys. As I understand it, transactions used in this way will ensure that uniqueness is not violated due to concurrent write operations conflicting with each other.

It doesn’t reach the original goal I had in mind of making it impossible to have a duplicate value for that predicate in the database, which could happen if someone wrote without checking to see if the value already exists. Maybe this is OK though, provided no one writes directly to the database but rather goes through an API that enforces this check for them.

My frame of reference for this request is from the relational database world, where a unique index on a column would prohibit a duplicate value ever existing in that table for that column. I like the “security blanket” that this database-level check provides, especially for cases where a violation would break the application. So that even if someone messes up with a mutation, the constraint can never be violated because the database would reject the transaction. But maybe this does not translate naturally to Dgraph or the use cases you anticipate?

Either way, thanks for your responses, and thanks @calummoore for writing the client library for node which I expect we’ll be integrating into our code base within the next couple of months.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/2/2b38fdece2abe5814f2e51bee69d1e67fc304b0a.png) [@system](https://discuss.dgraph.io/u/system)\
**Post date:** [December 18, 2017, 2:42pm UTC](https://discuss.dgraph.io/t/unique-indexes-on-predicates/1964/8 "2017-12-18T14:42:33Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.