sorenbs

# source: https://eu1.prisma.sh/sorena4/r3/dev
# timestamp: Sun May 13 2018 20:42:54 GMT+0200 (CEST)

type AggregateUser {
  count: Int!
}

type BatchPayload {
  """The number of nodes that have been affected by the Batch operation."""
  count: Long!

sorenbs

type User {
  id: ID! @unique
  name: String!
  email: String! @unique
  isAdmin: Boolean @default(value: "false")
  posts: [Post!]!
}

type Post {
  id: ID! @unique

sorenbs

It seems that our thoughts on this topic are converging. I will attempt to capture all facets in a single piece of writing that we can all sign off on, and use as the basis for a pr to the schema spec.

# Relations

Relations is a high-level construct in Prisma and a key value proposition compared to other data access libraries. The relation construct is a convenient way to apply the common pattern of using keys stored in one or more fields in a model to point to a specific record of another model.

**Explicit relation** The relation can be set up explicitly by defining the referenced field:

> Note: the syntax below is omitting any details not related to the concept it explains

sorenbs

It seems that our thoughts on this topic are converging. I will attempt to capture all facets in a single piece of writing that we can all sign off on, and use as the basis for a pr to the schema spec.

Relations

Relations is a high-level construct in Prisma and a key value proposition compared to other data access libraries. The relation construct is a convenient way to apply the common pattern of using keys stored in one or more fields in a model to point to a specific record of another model.

Explicit relation The relation can be set up explicitly by defining the referenced field:

Note: the syntax below is omitting any details not related to the concept it explains

sorenbs

Thanks Matt!

That is certainly a valid argument regarding implicit many-many relations, but not for the reason you have described. As I wrote in [339](https://github.com/prisma/specs/issues/339#issuecomment-559534963), I think implicit many-many is a solved problem: Introspection and Lift should both simply follow our convention when printing and reading the schema.

---

The main reason I am interested in including the implicit many-many syntax is that they enable a simpler Photon API for the majority that does not need extra fields on the relation table.

### Traversing implicit many-many relation:

sorenbs

Thanks Matt!

That is certainly a valid argument regarding implicit many-many relations, but not for the reason you have described. As I wrote in 339, I think implicit many-many is a solved problem: Introspection and Lift should both simply follow our convention when printing and reading the schema.

---

The main reason I am interested in including the implicit many-many syntax is that they enable a simpler Photon API for the majority that does not need extra fields on the relation table.

Traversing implicit many-many relation: