Запрос Graphql, возвращающий нуль для реляционного документа, поле отсутствует в запросе, но присутствует в primsa admin

Question

Когда я просматриваю документ в Prisma Admin, я вижу location поле, но когда я запускаю запросы к этой базе данных, значения всегда равны нулю во внешнем интерфейсе и не возвращаются преобразователем вообще.

Я посмотрел на Почему запрос GraphQL возвращает ноль? но ни один из этих случаев не соответствует и не говорит о коренной проблеме из того, что я могу сказать.

Я пытался разобраться в этой статье, но не смог реализовать так, чтобы я мог составить запрос, который на самом деле запускает: https://www.prisma.io/tutorials/a-guide-to-common-resolver-patterns-ct08/

Настройка соответствует продвинутому курсу Web Bos и выглядит следующим образом:

Создать приложение React -> Apollo-клиент -> Сервер йоги -> Prisma Server (sql)

Я ходил туда-сюда, используя типы ввода, упрощая распознаватели до минимума, запрашивая только один документ, а не массив документов. Варианты, которые я бы предпочел не использовать, - это использование скалярного типа Json и пропуск вложенной структуры в пользу плоской структуры.

Внешний интерфейс:

const CREATE_MISSION = gql`
  mutation CREATE_MISSION($title: String!, $description: String!, $bounty: Int!, $image: String, $postedBy: String!, $location: LocationInput) {
    createMission(title: $title, description: $description, bounty: $bounty, image: $image, postedBy: $postedBy, location: $location) {
      id
      title
      bounty
      image
      description
      postedBy
      location {
        id
        lat
        lng
      }
    }
  }
`;

schema.graphql:

input LocationInput {
  lat: Float!
  lng: Float!
}

type Mutation {
  createMission(
    title: String!,
    description: String!,
    bounty: Int!,
    image: String,
    postedBy: String!,
    location: LocationInput
  ): Mission!
}

datamodel.graphql:

type Location {
  id: ID! @id
  lat: Float!
  lng: Float!
}

type Mission {
  id: ID! @id
  title: String!
  description: String!
  bounty: Int!
  image: String
  postedBy: String!
  location: Location @relation(name: "MissionStart")
  end: Location @relation(name: "MissionEnd")
  dispatcher: User @relation(name: "Dispatcher")
  activeUser: User @relation(name: "Active")
  appliedUsers: [User] @relation(name: "Applicants")
}

Mutations.js

  async createMission (parent, args, ctx, info) {
    console.log(`Create Mission server side`)
    // let { input } = args
    console.dir(args)
    const mission = await ctx.db.mutation.createMission({
      data: {
        ...args,
        dispatcher: {
          connect: {
            id: args.postedBy
          },
        },
        location: {
          create: {
            lat: args.location.lat,
            lng: args.location.lng
          }
        }
      },
    }, info);
    return mission
  },

Запрос детской площадки:

{
  mission (id:"someid") {
    title
    description
    location {
      lat
    }
  }
  location(id:"id_asPerTheDB ") {
    lat
  }
}

возвращает:

{
  "data": {
    "mission": {
      "title": "Take me the airport",
      "description": "so I can fly",
      "location": null
    },
    "location": {
      "lat": 30.2255867
    }
  }
}

Согласно возвращенному значению на детской площадке, я не могу получить это местоположение из БД с помощью простого вложенного запроса. Я пытался использовать следующий преобразователь (запрос на бэкэнд), но это всегда null за m.location

async missions (parent, args, ctx, info) {
    const missions = await ctx.db.query.missions()
    return Promise.all(missions.map(async m => {
      if (m.location) {
        const location = await ctx.db.query.location({where: { id: m.location.id }})
        return Object.assign(m, { location })
      } else return m
    }));
  },

и еще из Призма администратора:

Answer 1

Вау, нереально, так что единственное, что мне нужно было сделать, это пройти info на запрос...

async missions (parent, args, ctx, info) {
    const missions = await ctx.db.query.missions({}, info)
    return missions
  }

Все данные, которые я хочу, теперь передаются клиенту, информация, очевидно, содержит детали, необходимые для обработки отношений, господи! 2 дня спустя лол.