Prisma1: Relations are not being returned using Mongo Connector with Prisma Client

[iagomelanias]

Describe the bug
Hi! 👋
In the recent alpha/beta releases, a found a bug/different behavior using Prisma Client. After creating a document with embed/inline relations, the data from this relation is not being returned.

To Reproduce
Steps to reproduce the behavior:

1. Create three different relations and deploy the changes. Mine are:

type Recipe {
  id: ID! @id
  name: String
  ingredients: [Ingredient!]! @relation(link: INLINE)
  author: Author! @relation(link: INLINE)
  createdAt: DateTime! @createdAt
}

type Author {
  id: ID! @id
  name: String
}

type Ingredient {
  id: ID! @id
  name: String
}

1. Run a mutation using the Playground. Mine is:

mutation {
  createRecipe(
    data: {
      name: "Prisma with Mongo"
      author: { create: { name: "Prisma Team" } }
      ingredients: { create: [{ name: "Prisma" }, { name: "Mongo" }] }
    }
  ) {
    id
    name

    author {
      id
      name
    }

    ingredients {
      id
      name
    }
  }
}

1. Notice everything is fine. Now try to do the same using Prisma Client. In my case, i'm using the TypeScript client. That's how it would look like:

import { prisma } from './clientTs';

(async () => {
  const recipe = await prisma.createRecipe({
    name: 'Prisma with Mongo',
    author: {
      create: {
        name: 'Prisma Team',
      },
    },
    ingredients: {
      create: [
        {
          name: 'Prisma',
        },
        {
          name: 'Mongo',
        },
      ],
    },
  });

  console.log(recipe);
})();

1. The recipe variable contains a object with only id, name and createdAt. Both ingredients and author are not being returned, but they're being added to the collection.

Expected behavior
Both ingredients and author should be returned.

Versions (please complete the following information):

• OS: macOS Mojave
• prisma CLI: 1.22.0-beta.0
• Prisma Server: 1.22.0-beta.0
• Prisma Client Lib: 1.22.0-beta.0

Additional context
I'm not sure if that was intentionally changed or it's a bug. 🙃

[SilencerWeb]

I have the same or similar problem. In my case I use demo server.

I have such datamodel:

type Rule {
  id: ID! @unique
  name: String! @unique
  options: [RuleOption!]! @relation(name: "RuleOnRuleOption" onDelete: CASCADE)
}

type RuleOption {
  id: ID! @unique
  name: String!
  value: String!
  rule: Rule! @relation(name: "RuleOnRuleOption")
}

And when I'm trying to make a query like this I get null in the field options even if it is not empty (checked on app.prisma.io):

query {
  rules {
    options {
      name
    }
  }
}

Versions:

• OS: macOS Mojave
• prisma CLI: prisma/1.20.7 (darwin-x64) node-v11.0.0
• Prisma Server: 1.20.7
• "graphql-yoga": "^1.16.7", "prisma-client-lib": "^1.20.7", "graphql": "^14.0.2"

EDIT: I have just tried to make the same query right from Prisma endpoint instead of the server that runs using graphql-yoga and I got options. So the problem is in graphql-yoga or generated client.

[timsuchanek]

@iagomelanias thanks for reporting. What you are reporting is 100% correct and expected behavior. The typings of the createRecipe mutation don't change depending on your input right now, as that is not possible to implement in a clean way with TypeScript.

The convention is, that the client always returns only the scalar fields of a type.

We're working on a new API to also allow deep related data to be returned.
However, this is the expected behavior for now. You can also check the return value in the TypeScript typings.

[timsuchanek]

@SilencerWeb can you please post the code where you're invoking the Prisma Client?
Where are you making the query you posted? In the Playground?

[SilencerWeb]

@timsuchanek

Can you please post the code where you're invoking the Prisma Client?

Can you explain better what kind of the code?

Where are you making the query you posted? In the Playground?

I tried both in the playground and on the frontend, the result is the same. In the end I just rolled back to old Prisma API (version 1.5.3) and it works perfect right now.