@id as the combination of two things (composite index)

Users GraphQL
4

Man this keeps coming up a lot here lately. IMHO this is a modeling problem rather than a unique key constraint problem. We call it a unique key constraint because we have been stuck with RDBMS for so long.

The other thing is that GraphQL fails to recognize what Dgraph terms facets and even Dgraph doesn’t handle facets all too well (not 1st class citizens of the graph).

So what is the fix then? How can we have these properties on an edge and multi-id constraints? The only answer we have right now (and probably only one we will have for a very long time) is to create what I term linking nodes as you described above.

This makes some things more difficult such as filtering and ordering with nested values but it is possible.

Modeling the jobs use case becomes something like:

type Person {
  id: ID!
  name: String!
  applications: [Application]
  postedJobs: [Job]
  reviewedApps: [Application]
}
type Job {
  id: ID!
  name: String!
  applicants: [Application]
  filledBy: Applicant
  postedBy: [Person] @hasInverse(field: "postedJobs")
}
type Application {
  id: ID!
  appliedTo: Job! @hasInverse(field: "applications")
  applicant: Person! @hasInverse(field: "applicants")
  appliedAt: DateTime!
  reviewed: [Person] @hasInverse(field: "reviewedApps")
}

How does this model fail to meet the jobs use case?

Every Person can have many applications and those applications each refer to only one person and one job, so the only thing lacking would be an Auth rule to prevent the same application to be created between the same Job/Person.

This last part is business logic. We are just so accustomed to creating pivot tables with unoquely constrained keys to apply this business logic rule, but the same is possible with Dgraph GraphQL with auth rules.

1 Like