Schema definition and predicates in Dgraph

[fcpunk (Fcp)]

Hi,

I have a question about schema and predicates in Dgraph, the documentation is a bit confusing.

Let’s say I need to define an entity called user which has the following attributes:

• email
• password
• full name
• company
• address

I define it as following:

user.email: string @index(exact) .
user.password: password .
user.full_name: string .
user.company: string .
user.address: string .

As result in Ratel I see a list of predicates and no types.

Questions:

1. Is it the correct way to do so? Or should I define type user with such fields?
2. I can’t use GraphQL queries on Dgraph with such schema because it says there’s no type user defined in the schema.
   For instance, such GraphQL query will complain about the absence of user type:

{
    user {
        email
    }
}

A DQL query like the following works though and returns all user entities:

{
  users(func: has(user.email)) {
    uid
    user.email
    user.password
    user.full_name
    user.company
    user.address
  }
}

This makes me wonder how exactly Dgraph groups predicates (attributes) user.* under a single entity without defining a type?
Mutation like the following works fine:

{
  "set": [
	  {
		"uid": "_:new_user",
		"user.email": "some@email.com",
		"user.password": "password",
		"user.full_name": "John Doe",
		"user.company": "John Doe Inc.",
		"user.address": "USA"
	  }
  ]
}

[MichelDiz]

@fcpunk

As result in Ratel I see a list of predicates and no types.

The predicate type and the Type Definition are two different things. The predicate definition is where you will define the type of value(value edge), indexing, and other directives. The Type Definition, on the other hand, is where you will define the “format” of an entity. The two things are different and you have to assemble the two, in order to mount your entity definition you have to have your “predicates/edge” established. It is only in GraphQL that this is automated for you.

@fcpunk

Is it the correct way to do so? Or should I define type user with such fields?

I covered this above.

@fcpunk

I can’t use GraphQL queries on Dgraph with such schema because it says there’s no type user defined in the schema.

Note that the entity type in GraphQL is Pascal Case if I’m not wrong. But pretty sure that the first letter is uppercase. So this should be reflected on the prefix of your predicates.

@fcpunk

under a single entity without defining a type?

The GraphQL feature does that under the hood. Not DQL.

@fcpunk

"uid": "_:new_user"

Not important, but, you don’t need the Blank node there. Only if you are sending a complex structure that needs to be linked on the fly. But again, not a big deal.

[verneleem]

If you want to use GraphQL and DQL, define your GraphQL schema types and let Dgraph generate the DQL schema off from that.

@fcpunk

1. For instance, such GraphQL query will complain about the absence of user type:

{
    user {
        email
    }
}

No GraphQL queries are generated to use without first defining the GraphQL schema types.

define

type User {
  id: ID
  email: String @search(by: [hash])
  password: String
  full_name: String # prefer camelCase fullName
  company: String
  address: String
}

And then mutate with addUser, updateUser, and deleteUser. And query with queryUser and getUser

[fcpunk (Fcp)]

@MichelDiz @verneleem thanks for the answers.

I come from a relational databases background and can’t match what Dgraph does with rows/tables (or entities/attributes in other words) and wording in the documentation confuses me a lot.
Does Dgraph actually create an entity with such attributes in the way I do or these are random sets of data that can’t be correctly queried/updated/stored?
Or does it create a node with these attributes which are not following any type at this point?
I saw a definition of fields sample in the documentation here: https://dgraph.io/docs/query-language/schema/#adding-or-modifying-schema but there’s no definition of a GraphQL type. Do I need to repeat all type information in the type definition or just list the names of the attributes?
What user.* actually means? Is that a namespace? Can it be get rid of in the type definition?

Thanks

[verneleem]

First there is so much value in this post for new users:

New to Dgraph? DQL vs. GraphQL, Endpoints, Headers, and Schema Translation

I would like to better understand the relationship between the DQL schemas and the GraphQL schemas This statement and a multitude of related questions (see References) have prompted me to write this to help new users. I remember when I started on the Dgraph road. Why were there so many endpoints? Which one should I use when? What is graphql±? (Meaning to me “GraphQL more or less.” Now it is commonly called DQL to avoid confusion and easier to say/write) Should I write my schema in GraphQL or …

@amaster507 also came from a sql background too.

Beyond that, it is difficult to forget what you know concerning rows/tables. Here is a learning course made just for you:

https://dgraph.io/learn/courses/datamodel/sql-to-dgraph/overview/introduction/

And also check out

https://dgraph.io/learn/courses/datamodel/evolution/overview/introduction/

these courses focus on the GraphQL but as DQL is the core under the GraphQL API endpoint it very much applies to DQL in general as well.

@chewxy wrote a blog that gets down to some of the lower level concepts of Dgraph too:

Graph Database Basics: Graphs - Dgraph Blog

[MichelDiz]

@fcpunk

Does Dgraph actually create an entity with such attributes in the way I do or these are random sets of data that can’t be correctly queried/updated/stored?

I don’t understand the question

Let’s state some guidelines here.

• If you are looking to work with GraphQL, never model your graph in DQL, model it in GraphQL and then you can use DQL. If you are only looking for DQL, forget about how Dgraph models GraphQL and focus only on DQL.

• If you intend to use GraphQL, I would recommend that you study GraphQL only and focus on the tutorials and material that Dgraph has in relation to GraphQL and our directives. Forget about DQL for now.

• Do not read anything related to GraphQL or DQL at the same time. If you’re learning one, focus on it.

• If you want to start with DQL and later on you want to use GraphQL, it will be a little difficult, but you can migrate the entire DB to the GraphQL Model with Upsert Block.

• When you are familiar with one or the other, you can explore further.

• For those who are just starting out and want to guarantee future support for GraphQL. I would learn GraphQL, even though I know I would not use the full potential of Dgraph.

@fcpunk

Or does it create a node with these attributes which are not following any type at this point?

All these questions would be YES for GraphQL. Not DQL. With DQL everything is manual. It is much more powerful, but it requires mastering the lang and Graph Modeling.

@fcpunk

but there’s no definition of a GraphQL type.

Don’t mind with those. These docs are just for DQL(We have GraphQL docs too, focusing on our features). If you need to go deep in GraphQL go to GraphQL Specs on their website. They have complete and technical documentation for GraphQL. And Dgraph’s GraphQL is fully compliant with that.

@fcpunk

Do I need to repeat all type information in the type definition or just list the names of the attributes?

In the Type definition, you gonna list the predicate that the entity will have. There’s no extra info for Type Def.

@fcpunk

What user.* actually means?

In GraphQL is just an internal convention for the GraphQL feature. Is the internal modeling.

@fcpunk

Is that a namespace?

Nope.

@fcpunk

Can it be get rid of in the type definition?

If you are using GraphQL and wanna use DQL, you have to follow the internal modeling for GraphQL. Or you have some extra steps to deal with. That’s best to follow now that you leave it for later.