Как использовать один и тот же сгенерированный идентификатор в двух полях prisma-graphql
Я реализую модель данных graphql prisma. Здесь у меня есть тип под названием BankAccount . Возможно, мне также потребуется обновить и удалить их. Я реализую это как неизменяемый объект. Итак, при обновлении я добавляю обновление существующей записи как IsDeleted и добавляю новую запись. И при обновлении существующей записи мне нужно сохранить идентификатор предыдущей записи, чтобы узнать, какая запись обновлена. Итак, я придумал такой тип
type BankAccount {
id: ID! @unique
parentbankAccount: String!
bankName: String!
bankAccountNo: String!
isDeleted: Boolean! @default(value: "false")
}
Здесь parentBankAccount сохраняет я бы предыдущего BankAccount. Я думаю, когда создание банковский счет, установите parentBankAccount так же, как id, поскольку у него нет родителя. Дело в том, что я не уверен, что это возможно. Я немного новичок в GraphQL. Таким образом, любая помощь будет оценена.
Спасибо
Ответы 1
В GraphQL, как правило, если один объект ссылается на другой, вы должны напрямую ссылаться на этот объект; вы бы не вставили его идентификатор. Вы также можете сделать поля обнуляемыми, чтобы поддержать случай, когда некоторые отношения просто не существуют. Тогда для этого конкретного поля это будет выглядеть так:
type BankAccount {
parentBankAccount: BankAccount
...
}
и это поле будет null всякий раз, когда у учетной записи нет родителя.
На уровне API описанный вами макет кажется немного странным. если я позвоню
query MyBankAccount {
me { accounts { id } }
}
Я верну какой-нибудь уникальный идентификатор. Я был бы немного удивлен, если бы позвонил позже
query MyBalance($id: ID!) {
node(id: $id) {
... on BankAccount {
name
isDeleted
balance
}
}
}
и узнаю, что мой аккаунт был "удален" и что баланс недельной давности.
Использование неизменяемых объектов в базовом хранилище данных имеет некоторый смысл, особенно из соображений возможности аудита, но, как правило, это не то, что вы можете напрямую раскрыть через API GraphQL (или большинство других уровней API: это было бы в равной степени удивительно в среде REST, где URL-адрес объекта должен быть постоянным).