Flexible Schema/Types with DGo

Users Dgraph
#1

I heard on Go Time where Francesc mentioned that by default, dgraph is very flexible and will let you write any data you want. I believe he mentioned that if you try to query for a predicate that doesn’t have an index, this will fail, but it sounded like everything else was fairly flexible.

I’m using DGo, and I have several types defined as Go structs (with appropriate JSON tags and DType field). I have yet to get DGraph to recognize my types without explicitly defining them in the schema as well. If I install a minimal schema that defines, say, a single index, that Alter will be accepted, as will any Mutates where I pass in my types. Both operations succeed. Yet when I go to Ratel after these, there are no types listed.

I tried searching the docs for answers but am coming up short. In addition, all of the tutorial content I’ve seen defines all types explicitly in the loaded schema. So I’m wondering if I just misunderstood the intent behind the statements about flexible schema. It would be ideal that during development, I could just work with Go types and not worry about my dgraph schema so much.

Any ideas?

#2

Type system will only works once you define types and specify types for the nodes in the graph. Dgo will not automatically use the Go Types and add them to Dgraph Types. This is something that may be nice to have, though, I wonder how it would be easily implemented in Go client (dgo) and other clients.

#3

Hm. I’m wondering what @francesc was talking about on the podcast, then. It sounded like dgraph was able to let you just start writing data without having to define a strict schema - but perhaps that only applies to predicates? Anyways I feel like this is a core concept and I want to make sure I “get it”, so some elaboration on what’s flexible during “development time”, and what’s not would be appreciated - and if there are differences in this flexibility between predicates and types as well - it is starting to sound like they’re treated a little bit differently.

#4

I think the type system would only work when you add types and associate those types to the nodes in your graph. That part if not “flexible”. Predicates and their schema, on the other hand, are created on the fly without needing to define them beforehand.

#5

I remember what @francesc was saying and completely agree with him. Podcast here

He was talking about the benefits of being able to work ‘Schemaless’ with your databse until you were ready to define you database Schema rules.

Basically you can put whatever you want into DGraph with the restrictions in your code without having to define any strict schema rules on the database until you’ve decided what you’ll likely need.

The advantage of this is it allows you develop quickly before your application has to be ready for production as your code sets the rules on what goes in and out of the database with no ‘checking’ done by the database itself.

#6

Yes, I get all that and appreciate the benefit. It appears my confusion was caused by the fact that this flexibility only extends to predicate definitions, not to type definitions as well. It may be useful to make this distinction more obvious; I doubt I’m the only one that assumed this flexibility was evenly applicable to types and their predicates.

#7

Will you explain, may be one more time, what did you expect as a default behaviour for types? I cannot think of a way where Dgraph could create types by default and attach them to the nodes. Feel free to create a feature request on GitHub and we would be happy to look into it.