RFC: enhancement over dgraph schema

Issues Dgraph Clients
, ,
1

Moved from GitHub dgraph-js/117

Posted by shreyansh-zazz:

Overview
Users should be able to define DGraph schema in object format. Defining schema in an object format will enable us to provide more validations to the schema in a clearer way like validation for each predicate, e.g.

UserSchema = new DgraphSchema({
    username: {
        type: 'String',
        index: true,
        immutable: true
    },

    password: {
        type: 'Password',
        min: 6,
        max: 26
    },
})

Motivation
A big motivation for such a feature comes from the package mongoose which a MongoDB client for javascript.

Action Items

  • Support DgraphSchema in an object format
  • Provide basic validation options such as:
    • immutable: [true | false]
    • min: [int] and max: [int]
    • unique: [true | false]
    • required: [true | false]
    • match: [new RegExp()]
    • default: [any] // default value for the predicate
    • lowercase: [true | false] // change the string to lowercase before saving into the DB
    • uppercase: [true | false] // change the string to uppercase before saving into the DB
  • return formatted error if provided data fails against the schema
1 Like
2

shreyansh-zazz commented :

I am happy to contribute but I will be needing some guidance. If anyone here would like to work on this with me please let me know.

3

jarifibrahim commented :

cc @vardhanapoorv

4

vardhanapoorv commented :

Hi @shreyansh-zazz
I like the idea. You can raise a draft PR (also include an example) and I can help you with your questions.

5

shreyansh-zazz commented :

Before proceeding, we have to make a decision on DgraphClient. There are two options as follows:

  1. new Dgraph.createClient(..args) will create a single DB client instance and all further communications with the database will be done using this client. (current approach)
  2. Let Option 1 be there and we can also expose an API such as Dgraph.connect(...args) which will take the same arguments as createClient(...args). The only difference will be that Dgraph.connect(...args) will set the default DB connection, meaning we can directly use Dgraph.Mutation(), Dgraph.Model() etc.

Here I am missing the DgraphClientStub because I don’t really understand why we need this when we can simply use Dgraph.createClient()

6

shreyansh-zazz commented :

Also, I think the API is pretty complicated. Maybe we can try to simplify that? There are too many new variable creations to perform one simple mutation, to be honest.

There must be some reason that I am not aware of for this decision, @vardhanapoorv can you explain to me little about this, please?

7

@vardhanapoorv any update on this?

8

AFAIK one client can have many stubs to different servers in a cluster or across clusters for example

I might be able to help depends on your needs.

9

Hi @spinelsun

My idea is something similar to what we have with mongoose client for MongoDB. Not the way we execute queries but how we define the schema and their respective validations.

The idea is very vague and I haven’t thought it through, it would be better if we would discuss this on a zoom call or something. Let’s evaluate the idea, and see if it make sense for the end-user and then we can lay out a roadmap for this.

I would be awesome if someone from Dgraph can pitch in as well, I think @vardhanapoorv was interested.

Anyways, let me know your thoughts on this.

1 Like
10

@shreyansh-zazz I don’t see much of a benefit of adding connect. Regarding the DgraphClientStub @spinelsun is correct.
I like the idea regarding the schema. I would suggest try with something basic to get started on that and just play around a bit locally.
Let me know if you have any other questions.

1 Like