Как использовать один и тот же сгенерированный идентификатор в двух полях prisma-graphql - PullRequest
Новая
       18

Как использовать один и тот же сгенерированный идентификатор в двух полях prisma-graphql

0 голосов
/ 01 марта 2019

Я реализую модель данных graphql prisma.Здесь у меня есть тип с именем BankAccount.Возможно, мне придется обновить и удалить их.Я реализую это как неизменный объект.Итак, при обновлении я добавляю обновление существующей записи как IsDeleted и добавляю новую запись.И при обновлении существующей записи мне нужно сохранить идентификатор предыдущей записи, чтобы знать, какая запись обновляется.Итак, я придумал такой тип 

type BankAccount {
  id: ID! @unique
  parentbankAccount: String!
  bankName: String!
  bankAccountNo: String!
  isDeleted: Boolean! @default(value: "false")
}

Здесь parentBankAccount сохраняет id предыдущего BankAccount.Я думаю, когда создает банковский счет, устанавливая parentBankAccount так же, как id, поскольку у него нет родителя.Дело в том, что я не уверен, что это возможно.Я немного новичок в GraphQL.Таким образом, любая помощь будет оценена.Спасибо

1 Ответ

0 голосов
/ 01 марта 2019

В GraphQL, как правило, если один объект ссылается на другой, вы должны напрямую ссылаться на этот объект;Вы бы не вставили его ID.Вы также можете сделать поля обнуляемыми, чтобы поддержать случай, когда некоторые отношения просто не существуют.Тогда для этого конкретного поля это будет выглядеть как 

type BankAccount {
  parentBankAccount: BankAccount
  ...
}

, и это поле будет null всякий раз, когда учетная запись не имеет родителя.

APIУровень, макет, который вы описываете, кажется немного странным.Если я позвоню 

query MyBankAccount {
  me { accounts { id } }
}

, я верну какой-нибудь уникальный идентификатор.Я был бы немного удивлен, позвонив позже 

query MyBalance($id: ID!) {
  node(id: $id) {
    ... on BankAccount {
      name
      isDeleted
      balance
    }
  }
}

и узнав, что моя учетная запись была "удалена" и что баланс за неделю назад.

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

...