Has there been any progress on the type system?
At the moment it seems that schema applies globally to all nodes, so effectively there is one global type?
What would be really nice, is optional types. So you can specify schema/types for nodes (and sub-nodes) if you want them, but use a default Node
type (which would work in a similar way to the current global Dgraph schema works).
Reasons why types are useful:
-
You can have the same field name represent different types of values, depending on the node type. E.g. title
of a Post
is different to a title
for a User
.
-
You could request a list of a specific type, without having an ID
(so give me first 10 nodes of type User
), exploring data would then become easier too (as you wouldn’t have to always start with an ID/filter)
-
You can specify a field to be indexed for a specific node type only.
-
You can easily identify the type of node and what is trying to represent (without implementing a custom solution). This allows you to perform normalization on the client side.
-
It prevents you from putting bad data into your database.
-
It would fit much better with GraphQL (meaning it would be easier to create a GraphQL layer on top of Dgraph) and would make the transition to Dgraph easier.
-
Your database becomes self-documenting (through introspection).
GraphQL
type User {
title: String # E.g. Mr, Mrs, Ms - don't index!
name: String!
age: Int!
posts: [Post]
}
type Post {
title: String! @index # E.g. A Great Post - index!
user: User!
comments: [Comments]
}
type Comments {
text: String!
user: User!
}
Dgraph
title: String # Ambiguous
name: String
age: Int
# posts: [Post] # No equivalent
# comments: [Comments] # No equivalent
# user: User! # No equivalent
New Approach
You would be able to set up specific types and have them attached to the root query.
mutation {
type Users {
name: String
}
schema {
users: [Users]
}
}
query {
users(first: 10) {
name
}
}
If a user wanted to keep with the current Dgraph style, they could use Node
. Node
could be a default type, used without configuration but amended as required. Or, it could be a base type, so all other types would extend from it and it could be used as kind of Any):
mutation {
type Node {
title: String
name: String
age: Int
}
type User extends Node {
name: String @index
}
schema {
nodes: [Node] # All nodes, regardless of type
users: [User] # All nodes of type User
}
}
query {
customLookup1: nodes(id: $id) {
title
}
nodes(first: 10) {
title
}
}
You could keep the current RDF type for set
, which I really like (especially as you can do bulk transactions).
Not saying this is exactly the way you would want to do it, but wanted to provide some food for thought.