Можно ли иметь разные типы для одного и того же поля между схемой Prisma GraphQL и моделью данных? - PullRequest
0 голосов
/ 02 мая 2019

Я новичок в Prisma / GraphQL.Я пишу простое приложение ToDo и использую Apollo Server 2 и Prisma GraphQL для бэкэнда.Я хочу преобразовать мое поле createdAt из модели данных во что-то более удобное для использования во внешнем интерфейсе, например строку даты UTC.Я думал о том, чтобы преобразовать сохраненное значение, которое является DateTime.

My datamodel.prisma имеет следующее для типа ToDo

type ToDo {
id: ID! @id
added: DateTime! @createdAt
body: String!
title: String
user: User!
completed: Boolean! @default(value: false)

}

Поле added является DataTime.Но в моем schema.js я перечисляю это поле как String

 type ToDo {
    id: ID!
    title: String,
    added: String!
    body: String!
    user: User!
    completed: Boolean!

  }

и преобразовываю его в свой преобразователь

 ToDo: {
    added: async (parent, args) => {
      const d = new Date(parent.added)
      return d.toUTCString()
    }

Это нормально для этого?То есть есть разные типы для одного и того же поля в datamodel и schema?Кажется, все работает хорошо, но я не знал, открывал ли я себя, чтобы идти дальше по дороге, следуя этой технике в других обстоятельствах.

Если так, то мне было интересно узнать, почемуparent.added в резольвере ToDo.added не запускает какой-то «бесконечный цикл» - то есть, когда вы обращаетесь к полю parent.added, он не обращается к резолверу для разрешения этого поля, которое обращается кparent.added поле и тд.(Думаю, это достаточно умно, чтобы этого не делать?)

1 Ответ

1 голос
/ 08 мая 2019

У меня только ограниченный опыт работы с Prisma, но я понимаю, что вы можете рассматривать его как дополнительный внутренний уровень GraphQL, взаимодействующий между вашим собственным сервером GraphQL и вашими данными (то есть базой данных).

Ваша первая модель (datamodel.prisma) использует улучшенный синтаксис Prisma и директивы для точного описания ваших данных и используется слоем Prisma, тогда как вторая модель использует стандартный синтаксис GraphQL для реализации того же объекта, что и действительный стандартный GraphQL. введите и используется вашим собственным бэкэндом.

Фактически, если вы посмотрите на него, вы увидите, что тип DateTime, используемый Prisma, на самом деле String, но, вероятно, используется Prisma для проверки форматов даты и времени и т. Д., Поэтому существует нет принципиального расхождения между обеими моделями. Но даже если бы было расхождение, это зависело от вас, так как вы могли бы использовать средства распознавания для переопределения данных, которые вы получаете от Prisma, прежде чем возвращать их из собственного бэкэнда.

Короче говоря, я хочу сказать, что вы имеете дело с двумя разными слоями GraphQL: Prisma и вашим собственным. И хотя роль Prisma состоит в том, чтобы точно представлять ваши данные в том виде, в каком они существуют в базе данных, и предоставлять вам широкий набор методов CRUD для работы с этими данными, ваш собственный уровень может (и должен) быть приспособлен к вашим конкретным потребностям.

Что касается вашего вопроса распознавателя, parent в этом контексте будет содержать объект, возвращенный родительским распознавателем. Представьте, что у вас есть запрос getTodo на уровне корня Query, возвращающий один элемент типа ToDo. Предположим, вы разрешаете это для действия Prisma по умолчанию, чтобы получить одно задание. Согласно вашему файлу datamodel.prisma, этот запрос будет преобразован в объект со свойством added (которое будет существовать в вашей БД в виде поля createdAt, как указано в директиве @createdAt Prisma). Так что parent.added будет содержать это значение.

Что делает ваш распознаватель added, это преобразовывает этот исходный фрагмент данных, превращая его в фактический объект Date, а затем форматирует его в строку UTC, что соответствует вашему schema.js файлу, где поле added имеет тип String!.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...