Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support 1 to 1 associations seems to fail in V1.1.0 #4080

Closed
pepoospina opened this issue Sep 27, 2019 · 3 comments
Closed

Support 1 to 1 associations seems to fail in V1.1.0 #4080

pepoospina opened this issue Sep 27, 2019 · 3 comments
Labels
area/schema Issues related to the schema language and capabilities. kind/bug Something is broken. status/accepted We accept to investigate/work on it.

Comments

@pepoospina
Copy link

What version of Dgraph are you using?

Dgraph version   : v1.1.0
Dgraph SHA-256   : 7d4294a80f74692695467e2cf17f74648c18087ed7057d798f40e1d3a31d2095
Commit SHA-1     : ef7cdb28
Commit timestamp : 2019-09-04 00:12:51 -0700
Branch           : HEAD
Go version       : go1.12.7

Have you tried reproducing the issue with the latest release?

I think that's the latest one.

What is the hardware spec (RAM, OS)?

Ubuntu 16.04, 16GB, don't think it's relevant here.

Steps to reproduce the issue (command/config used to run Dgraph).

run dgraph 1.1.0
clone this branch of this repo:
https://github.com/uprtcl/js-uprtcl-server/tree/duplicated-heads

npm install
npm test

Expected behaviour and actual result.

I configured the Perspective type as having one property called head of type uid (not [uid]). Check src/db/schema.ts and /src/db/dgraph.service.ts/

Since this issue was closed and added to V1.1.0, I expect that every time I set the head of a perspective the value is overwritten instead of added to the previous one.

In the last console.log there should be one single head edge. Instead, there are two.

[DGRAPH] getPerspectiveHead {
      query: 'query {\n' +
        '      perspective(func: eq(xid, zb2wwruCksbXqsGYMVHZsFi6TcWWW7rNTnerJN2RBzE5ZecDU)) {\n' +
        '       head {\n' +
        '         xid\n' +
        '       }\n' +
        '      }\n' +
        '    }'
    } { perspective: [ { head: [Array] } ] } {
      head: [
        { xid: 'zb2wwzqMtQFTuvXWtQGQchSCzfAjE4GEWJby3wxbRTabjnTkb' },
        { xid: 'zb2wwyEFUzAAdf7ww8FqGVorGhwgf5fejhSmdVw1vd2aZuRuC' }
      ]
    }
@MichelDiz
Copy link
Contributor

I think you've just defined the type schema. Dgraph won't check the type schema, you have to add in https://github.com/uprtcl/js-uprtcl-server/blob/05a19237417d7115e7457defe6d143e27a5cf8fb/src/db/schema.ts#L63 this:

head: uid .

@campoy
Copy link
Contributor

campoy commented Sep 27, 2019

Yeah, could you give us the result of running the following query?

schema {}

@campoy campoy added area/schema Issues related to the schema language and capabilities. kind/question Something requiring a response. kind/bug Something is broken. status/accepted We accept to investigate/work on it. and removed kind/question Something requiring a response. labels Sep 27, 2019
@campoy campoy mentioned this issue Sep 27, 2019
Closed
@campoy
Copy link
Contributor

campoy commented Sep 27, 2019

OK, I was able to reproduce the issue and I have a workaround for you.

The problem is that you didn't declare the head predicate in the Dgraph schema, you just created it as a field in the type Perspective.

This means Dgraph doesn't know about the head predicate at all! So when you create some data with a head predicate, Dgraph defaults to the [uid] type as it's supposed to.

So, in your case you should definitely add the following line to your schema:

<head>: uid .

This will enforce having the 1:1 relationship you wanted.

Additionally, if you want to avoid this behavior in the future and make sure no predicates are created without your permission, you should definitely protect the database by running your alphas with the --mutations=strict flag on.

$ dgraph alpha --help | grep mutations
      --mutations string            Set mutation mode to allow, disallow, or strict. (default "allow")

That will stop any mutations that don't follow the schema.

Finally, there's the question of whether the predicate should be created once we see it on a type.
I do think so, so I created #4085 to track it.

Thanks for the report!

Closing this issue now, feel free to reopen if there's anything else I missed.

@campoy campoy closed this as completed Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/schema Issues related to the schema language and capabilities. kind/bug Something is broken. status/accepted We accept to investigate/work on it.
Milestone
No milestone
Development

No branches or pull requests
3 participants
@campoy @pepoospina @MichelDiz