[RFC] Naming of reserved predicate for type system

(Martin Martinez Rivera) #1

The current implementation of the type system requires a predicate to specify the type of a node. It’s currently named simply “type” but a lot of users are already using this name and upgrading to 1.1 would involve migrating their data beforehand.

Other names have been suggested:

  • _type_
  • dgraph.type

Opening this post for more discussion.

UPDATE: (03/22/19)

dgraph.type = 5 votes

node.label = 2 votes

(Michel Conrado) #2

How this would look like in the schema and mutation? the user has to type in the “type” for each node in the mutation?

update:

I see:

{
		"set": [
			{
				"name": "Alice",
				"type": "Employee"
			},
			{
				"name": "Bob",
				"type": "Employer"
			}
		]
	}
(Lucas Wang) #3

+1 for dgraph.type
padding to reach 20 chars

(Michel Conrado) #4

In my opinion “type” is a good option it is much simpler. But to solve problems we should define solutions. Maybe modify the export to change the “type” that the user has (like a rename). Or maybe analyze if the Type that the user has can be adopted in the new Type System.

(Manish R Jain) #5

Opening it up to Dgraph community, so they can have a say.

(Manish R Jain) pinned globally #6
(Gus) #7

+1 for dgraph.type

(Aman Mangal) #8

Slightly different opinion, but I feel like type generally refers to value types. I am not so much pro “label”, but personally like it better than “type”. Could be “node.label” too.

Another suggestion “node.type” :stuck_out_tongue:

(Michel Conrado) #9

node.type makes sense.

(Paul Korzhyk) #10

+1 for dgraph.type

I think type (and less likely node.type) are already used in production by many people. Renaming a field in a schema can be painful, as I’ve learned while migrating Gru.

(Gus) #11

Let me try to explain why I think dgraph.type is useful.

  1. Clearly labels the predicate as something related to the database.
    Sure, maybe a user wants to use dgraph.type for their own application. Well, the user owns the data but Dgraph owns the process and this clearly indicates look but dont touch. A fair agreement between parties. Using plain type is bound to mistakes and confusion.

  2. Creates a namespace for any other future internal predicate names.
    I think it will be easier to alias internal Dgraph to GraphQL vars with dgraph.* to __*. When we detect the user needs an internal value the transform can be linear. Also, the namespace makes the internal logic a lot simpler to follow.

  3. Looks official and cool. :sunglasses:

(Paul Korzhyk) #12

Here’s how introspection is done in GraphQL:

In brief property named __type points to an object with possible fields name, kind, fields, ofType.

If we want to support GraphQL natively, for most definitions of “natively” we’d have to else use their approach or implement some kind of renaming.

(Joschka Tillmanns) #13

We solved this with dgx by prefixing all attributes on a node. So for instance name would become user.name. dgx.Dogma does that automatically for us, as long the type instances pushed to Dgraph implement a special Method Prefix() string that provides that prefix.

(August Hell) #14

+1 “dgraph.type”
I like namespaced keys as it makes it so obvious what value or kind of data is stored.
While transfering data from sql databases where DB or “db.” are often the package name or class prefix, I use “dg.” for refering dgraph data. So “dg.type” is maybe something to consider too, if you like that idea.

(Wildan Maulana Syahidillah) #15

+1 “dgraph.type”

Sounds official and reserved internally for dgraph.

(Martin Martinez Rivera) #16

Since most people agreed on it, I have renamed the reserved predicate to “dgraph.type”.