Schema review: new to DGraphj

App Development
1

Hello All!
I am first time using DGraph. I would love if anyone could review my schema.
It’s a very basic use case where I have two types of nodes: Tag and Resource. I want to keep the edges unidirectional, as I would query from both sides.
Additionally, I would often do an exact match on the ‘parentId’ field and ‘anyofterms’ on the key field.

var Schema = `
type Tag {
  resourceIds: [Resource] 
  organizationId: String
  parentId: String!
  key: String!
  value: String!
}

type Resource {
  name: String!
  tagIds: [Tag] 
}

name: String .
key: String @index(term) .
value: String .
resourceIds: [uid] @count @reverse .
tagIds: [uid] @count @reverse .
organizationId: String @index(hash) .
parentId: String @index(hash) .

`
2

You are mixing the DQL and GraphQL syntaxes here. This is not a valid schema. What are you placing to use primarily DQL or GraphQL to mutate and query your data?

3

Hi,
Thank you for your reply. I’ve started some implementation using DQL. I’ve been loading this schema so far and DGraph hasn’t complained about it yet.
I’m flexible with my backend implementation. I can go with either. Does DQL have performance benefits? If yes, what changes can be made it to make more efficient.

Thank you again!

4

^ so I don’t have to keep repeating the same explanations

1 Like
5

Thank you for the above blog. It was really helpful.
Updated my schema, what do you think about it now (made it DQL)

var Schema = `
type Tag {
  resourceIds [Resource] 
  organizationId string
  parentId string
  key string
  value string
}

type Resource {
  name string
  tagIds [Tag] 
}

name: string .
key: string @index(term) .
value: string .
resourceIds: [uid] @count @reverse .
tagIds: [uid] @count @reverse .
organizationId: string @index(hash) .
parentId: string @index(hash) .

`

Thank you again for your time and help.

6

A few questions…

What is your use case for parentId? Is this going to be used to look up something else? If so, it should be an edge not a predicate.

Are you going to want to keep resouceIds and tagIds in sync yourself manually? It might be easier to use just the reverse edge for whichever side seems more natural. I would keep the actual edge on the side where you write to most usually. (The primary type)

7

Thank you for your response. ParentId will be mainly used for lookups. You can think of it as n tags associated with one parent ID. How can I make it an edge?

In my implementation currently, I was syncing them manually. Is there a better way to do that? I would mostly write to resourceIds and update tagIds later. Can you help me with I would keep the actual edge on the side where you write to most usually. (The primary type) part?

Thank you so much again!

8

Hi @amaster507
Based on our previous discussion, I have updated the schema:

var Schema = `
type Tag {
  organizationId: string
  parentId: Tenant
  key: string
  value: string
  resourceIds: [Resource] 
}

type Resource {
  name: string
  parentId: Tenant
  type: string
  tagIds: [Tag]
  owner: User
  creator: User 
}

type User {
  name: string
  parentId: Tenant
}

# establish a hierarchical relationship
type Tenant { 
  name: string
}

name: string @index(hash) .
key: string @index(term) .
value: string .
resourceIds: [uid] @count @reverse .
owner: uid @reverse .
creator: uid @reverse .
tagIds: [uid] @count @reverse .
organizationId: string @index(hash) .
parentId: uid .
type: string @index(term) .

`

What do you think about this schema? Do you have any suggestions on how I can optimize this further?