Вопрос: что не так со списками и как правильно связать с "создателем" ( createdById String? @db.VarChar(32) CreatedBy User? @relation(fields: [createdById], references: [id]) ) ? Смотри модель пользователя текущего сайта, наверняка поймешь.
Спасибо! >>Но сущность типа Гриб лучше было бы сразу загнать в таблицу. То есть завести прям отдельную таблицу, в которой связаны по id пост и гриб? Тогда enum вообще лишний?
Нашел про списки: Правильно t.field('mashroom, { type: Mashrooms }) В целом да, правильно, но есть НО: ты прописал type: Mashrooms и здесь у тебя Mashrooms - это не строковое название типа, а именно сам объект, то есть Правильней указать строковое имя, то есть { type: "Mashrooms" } Вторая подсказка: категорически избегай названий типов с окончанием на s (то есть множественность). В каком-то месте тебе надо будет массив таких типов и как ты будешь писать? Mashroomss? Особенно не советую наименование типов (именно тех, которые идут потом в названия таблиц, а не колонки) на s заканчивать в самой призма-схеме. Призма втупляет с формированием имен множественных переменных и получается все очень плохо. Подсказка 3: имена типов в графе уникальные. Если ты назвал енам Mashroom, то имей ввиду, что потом если захочешь создать тип Mashroom (чтобы у него была своя таблица), не получится. Нельзя и тип и енам иметь с одним названием. Обычно енамы для каких-то совсем не больших списков используют (к примеру, статусов). Но сущность типа Гриб лучше было бы сразу загнать в таблицу.
Нашел про списки: Правильно t.field('mashroom, { type: Mashrooms })
Николай, привет! Ковыряю nexus, нужна помощь. Я добавил в схему призмы таблицу: Пишу проверку типов в нексусе для поста: Вопрос: что не так со списками и как правильно связать с "создателем" ( createdById String? @db.VarChar(32) CreatedBy User? @relation(fields: [createdById], references: [id]) ) ?
Совершенно не факт. Нужно тестирование проводить. Хотя вряд ли разница будет ощутимая. Но есть разница в восприятии и объеме кодовой базы.
Если правильно понимаю - и по времени быстрее должно работать?
Дима, в целом правильно, но очередность чуть другая. Надо так: 3. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/server/nexus/types надо добавить описание таблицы для nexus, который проверяет соответствие типов полей в gql 4. Сюда https://github.com/prisma-cms/nextjs-nexus/tree/master/src/gql добавляем .graphql для новой таблицы Судя по всему, ты думаешь, что сначала должно что-то появиться в /src/gql и только потом уже можно добавлять что-то в типы /server/nexus/types. Это не так. Если разбирать наименование папки /server/nexus/types, то здесь types - это не тайпскриптовые типы, а графкюэльные. То есть здесь надо более хорошо прокачаться в GraphQL и понимать, что там все есть типы (даже скалярные). При этом есть типы на чтение (все типы, что мы перечисляем в теле запроса для получения данных), а есть входящие типы (input-types), это все то, что мы передаем в параметрах. Nexus - это библиотека, которая позволяет генерировать GraphQL-схему (включая типы) на основе нашего кода. Для примера Таким образом мы описываем структуру GraphQL-типа User. Этот тип генерируется и попадает в server/nexus/generated/schema.graphql Это именно та схема, которую использует GraphQL-сервер. Посмотри внимательно эту схему у себя в проекте. Если ты там не видишь того, что ожидаешь получить на фронте, то ты этого не получишь. К примеру, у меня сейчас так (помимо прочего): То есть то, что я прописал в нексусе, попало сюда. И вот теперь этот тип я вижу и в плейграунде Вот пока ты в GraphQL-Playground не увидишь то, что ожидаешь, на фронте ты не сможешь это получить. И лишь только тогда, когда ты там увидишь желаемое, только тогда ты можешь добавлять фронтовые файлы .graphql и выполнять yarn generate:types, а иначе ты просто будешь получать ошибку.