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.