Self-referencing parent relationship not recognized by query filter in Slash API Explorer?

Issues Slash GraphQL
#1

What is the recommended schema for parent/child hierarchical relationships in DGraph/Slash?

I updated the demo Task schema to point to itself for a hierarchical, parent/child relationship for tasks:

type Task  {
	id: ID! 
	title: String! @search(by:[fulltext]) 
	completed: Boolean! @search 
	user: User!
	parent: Task
}

I can access the Parent value in Slash’s API Explorer queries when querying a task… but I can’t query tasks via a “Parent” query filter. I can’t use API Explorer to “return all tasks whose parent task id = 123”?

Thanks.

#2

Add the inverse of the relationship first:

type Task  {
  id: ID! 
  title: String! @search(by:[fulltext]) 
  completed: Boolean! @search 
  user: User!
  parent: Task @hasInverse(field: "children")
  children: [Task]
}

Note: For any existing relationships you will need to manually create the inverse.

For all future relationships, it will create the edges in both directions.

Then you could traverse from a parent to all of its children:

getTask(id: "0x7b) {
  children {
    id
    title
    completed
  }
}
1 Like
#3

Hey thanks a ton for the quick reply @verneleem.

Updated the schema… and went to update some mutations and queries and get the endless spinning ball all of a sudden… (Unrelated, Im sure. I assume it’s a DGraph Slash server hiccup…)

Chrome dev tools console: CORS connection error to my GraphQL API endpoint:

“Access to XMLHttpRequest at ‘https://myslashendpoint…dgraph.io/query’ from origin ‘https://slash.dgraph.io’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”

#4

Ah, viewing the endpoint directly = I hit limit of free test plan it seems within a tiny bit of test use in the past handful of minutes. Hhhm.

“You have reached your daily limit of data transfer. Please upgrade your plan at https://slash.dgraph.io”

Feedback for team:

  1. Give error notices in the Slash interface rather than endless spinning icon and CORS error messages in console.
  2. Give enough queries in trial version where users can actually test the product to see if it fits their needs.

Thanks.

1 Like
#5

Yes, 1Mb/day can be a lot unless you write a query in a way in a frontend app and call it infinitely for the same data (which I have done and learned the hard way). It can eat up that transfer data fast!

I can’t help you here other than saying I understand and upgraded a db from the free tier to a paid tier for this reason myself.

I think there was a 7 day free trial of the paid plan?? @gja is that still correct?

#6

Thanks @verneleem. Oddly, I’ve solely used the Slash API Explorer and Data Visualizer and a single Ratel query - and for roughly the exact same Task demo data: a dozen tasks and three authors. Seems super anemic.

But whatever. Will purchase and continue to test it out… Looking forward to testing out your parent/child solution! Thanks again.

#7

And related to both performance and parent/child relationships: my whole purpose for considering a graph db like Dgraph is the assumption that it may be a better performance fit for parent/child relationships + other, complex relationships vs a relational db.

Am I right in this assumption and do I need to consider other DGraph db architecture architecture issues here, or this built-via-Slash-GraphQL-schema is goo to go? Thanks.

#8

Yes, there is still a 7 day trial of the paid plan, but I think the messaging must have gotten lost. We’ll add it back.