Support 1 to 1 associations at the schema level

[camway]

Me and another member of the dgraph forum have been going back and forth on how exactly this should be done. Feel free to read

https://discuss.dgraph.io/t/return-single-object-instead-array-for-exactly-one-relation-between-node/2927/7

The solution proposed by bennyrio (the person I've been talking to in the forum) was elaborated on after creating this. I do not want to misrepresent his view on this so below is a direct link to his explanation:

https://discuss.dgraph.io/t/return-single-object-instead-array-for-exactly-one-relation-between-node/2927/8

The essence of my request is that I think we should change the schema so that uid associations are capable of being defined as 1 to 1. Unfortunately, my proposal will be a breaking change, but I think it will make uid predicates consistent with the other predicate types.

Currently a schema of this:

a: uid .
b: [string] .
c: int .

Exhibits these behaviors:

a is capable of returning 0 or more nodes
b is capable of returning 0 or more strings
c is capable of returning 0 or 1 integers

My proposal would look like this:

a: uid .
b: [string] .
c: int .
d: [uid] .

Exhibiting these behaviors:

a is capable of returning 0 or 1 nodes
b is capable of returning 0 or more strings
c is capable of returning 0 or 1 integers
d is capable of returning 0 or more nodes

This would also require that any mutation which would violate this 1 to 1 association should abort with an error.

This would also mean that existing schemas would have to be updated, but I believe this will make for consistency across all predicates types when defining a list vs a single item.

[ahopkins]

Honestly ... as a newcomer to dgraph ... this is how I initially expected it to work.

If I want to map multiple "things", I wrap it in []. For example: [str]. That makes sense.

EXCEPT if I am mapping to multiple uid. Then I just leave it as uid. That does not make sense.

[manishrjain]

Hmm... This looks like a very convincing argument. In essence, if you can have multiple edges from one node to another, the schema must be defined as [uid], and the result would be a list of JSON objects. Otherwise, if defined as uid, then there can only be at most one edge and the result would be a JSON map.

I haven't thought through all the implications of this, but as an initial thought, it makes a lot of sense to be this way.

[slawo]

There should be a consistency tag put on this.

[insanitybit]

The proposed behavior is absolutely what I had expected when going into dgraph, and I even just today had to remind myself that [uid] wasn't an option.

[camway]

@ahopkins and @insanitybit, that seems to be the general consensus. I don't know what it will take to get this implemented, but I think I can safely speak for us (and others) in saying we want this functionality. It seems like this is something many people have found workarounds for, but it seems like it's something the database should do for it's users.

[bandirsen]

@camway

Thing to consider, predicate with scalar value and predicate with uid relation is different thing.

p: [string] mean, a node can have zero or one of this predicate, and the predicate hold list of string value, its predicate/edge multiplicity is still zero or one, same as p: string, but the value type is different, now its a list of string.

while p:uid mean, a node can have zero or one of this predicate, and p:[uid] mean a node can have zero, one or more of this predicate, which mean predicate/edge multiplicity is changed.

The difference is clear when we do set mutation, in current implementation, when we do set mutation on a already existed scalar value predicate with a new value, it will automatically update the old value with new value (or if it was a list type, it will add new item to the list). On the other hand, set mutating on already existed uid predicate with new uid will add new uid-to-uid relation, which mean predicate/edge multiplicity is changed

Since this feature request is about predicate/edge multiplicity constraints not value type, I think it would be better if we implement this feature as '@' tag, just like @reverse tag, for example:
p: uid @one @index @reverse which mean a node can have zero or one of this predicate.
p: uid @many @index @reverse** which mean a node can have zero, one or more of this predicate

[ahopkins]

@bandirsen I cannot speak to the technical implementation reasons for one versus the other. But if it is something that can be accomplished (liminiting cardinality at the dB level), then it seems like a syntactic issue. And, it seems counterintuitive to handle cardinality with brackets in one place and a directive in another.

[camway]

@bandirsen I'm going to try to proceed through this as methodically as possible. Please tell me where I've gone wrong because I truly do not understand why you are still fighting this change.

A few notes.

p: [string] mean, a node can have zero or one of this predicate, and the predicate hold list of string value, its predicate/edge multiplicity is still zero or one, same as p: string, but the value type is different, now its a list of string.

p: [string] means a node can have zero or more of this predicate. Writing it in your form makes it sound worse than it is. It would be like saying I have (2mill/1mill) options, instead of saying I have 2 options.

while p:uid mean, a node can have zero or one of this predicate, and p:[uid] mean a node can have zero, one or more of this predicate, which mean predicate/edge multiplicity is changed.

In the proposed change, the simplified form is:
p:uid means zero or one
p:[uid] means zero or more

I know you've been pushing for this to be a directive since before I jumped on this bandwagon, and I'm not opposed to that being an option. I don't see any problem with adding a directive such as @one that causes the relationship to drop the array and retrieve just a single item. This would be useful for problems where I want a key in my response such as "most_recent_post" in my response shape. Of course the posts in this case need to hold zero or more, but in this use case it would be useful to not have it as an array. It would also be useful in certain cases to combine this with first, last, and order statements. This was why I didn't ask you to close your github issue, I thought both changes were equally valid.

What you have not addressed is the major inconsistency in the syntax when defining the schema. That is the primary problem this issue is designed to fix, and a fix for it appears no where in your argument. This issue is also designed to allow the database - at its schema level - to address the problem of one to one associations which your argument also fails to address.

The inconsistency issue is the primary problem here. It seems everyone who starts using Dgraph (including me) instinctively tries to use uid and [uid] because after seeing how all other predicates work, this would just make sense. It's counter-intuitive. Unless your solution includes a way to solve this inconsistency, then I cannot discount the value of this proposed change.

Please tell me if I've gone wrong somewhere. I do not understand your stance against this change, and I'm trying my best.

[bandirsen]

@camway @ahopkins

p: [string] means a node can have zero or more of this predicate

I think I was wrong all this time, I always thought in DGraph treat list type is someway like this.

<aNode> <aPredicate> ["string1", "string2", "string3"]

if it's treat like this:

<aNode> <aPredicate> "string1"
<aNode> <aPredicate> "string2"
<aNode> <aPredicate> "string3"

Then it p:[string] will have same behaviour like p:[uid] for all mutation process and my arguments to recommends predicate multiplicity as @ directive are wrong.

[camway]

@bandirsen I'd have to defer to the Dgraph team for that. Honestly, the internals of this database are something I find very interesting, but I struggle to understand how much of the system works. Part of this is I just don't have enough available time to invest in order to learn it. The other part - simply put - is it's complicated.

@manishrjain could you or another member of the team give us your thoughts on @bandirsen's post above?