Отношения и модели Vapor 4, требующие имени свойства ID - PullRequest
0 голосов
/ 17 июня 2020

Я пытаюсь настроить родительские обязанности в приложении (Vapor 4), и, хотя это возможно, я столкнулся с проблемой или, по крайней мере, с ограничением, которое приводит к использованию менее значимых имен свойств в модели.

Vapor 4 требует, чтобы свойство @ID называлось 'id' (var id: ...), тогда как в предыдущей версии имя свойства было определяемым и, следовательно, более значимым именем.

Для Например, таблица User: в наших пользовательских данных имя пользователя используется в качестве уникального ключа (а не первичного ключа), поэтому модель User определяется как таковая:

  // 'Unique key for the record.'
  @ID(custom: "sysid", generatedBy: .database)
  var id: Int?

  // Unique login name 
  @Field(key: "username")
  var username: String?

  // Password for this login.
  @Field(key: "password")
  var password: String
  ...

Имеет смысл и читается, и везде, где находится модель используется в приложении, разработчик знает, что поле Id - это системный идентификатор, а имя пользователя - это имя пользователя.

Внешний ключ в таблице правил и профилей использует имя пользователя в качестве внешнего ключа (по причинам устаревшего). Изменить это, хотя db и app в настоящее время невозможно.

С момента первоначальной реализации я читал и осознавал преимущества использования отношений (а не фильтров и объединений).

Чтобы использовать отношения в Vapor 4, я должен изменить определение модели на:

  // 'Unique key for the record.'
  @Field(key: "sysid")
  var sysid: Int?

  // Unique login name 
  @ID(key: "username")
  var id: String?

  // Password for this login.
  @Field(key: "password")
  var password: String
  ...

Мои определения модели менее значимы (хотя это действительно работает):

Конечно, это означает, что хотя- код .username теперь необходимо изменить на .id, что гораздо менее понятно.

В Vapor 3 мы могли определить имя свойства ID для чего угодно. Было бы намного проще, если бы в Fluent / Vapor 4 были разрешены пользовательские имена свойств, как в предыдущих версиях.

Мне было интересно, сталкивался ли кто-нибудь с этой «проблемой»? или имеет обходной путь, позволяющий моделям продолжать использовать значимые имена и по-прежнему обеспечивать правильную работу родительского контроля.

Я использовал эти простые пользовательские данные в качестве примера, но, конечно же, другие используют другие / значимые имена столбцов, которые страдают от моих. . раздражение?

Приветствуются любые советы / мысли Спасибо

1 Ответ

1 голос
/ 25 июня 2020

Обертки свойств отношений Fluent основаны на отношениях, определенных в свойстве id. Это позволяет вам создать дочерний элемент только с родительским идентификатором и без необходимости сначала искать родительский элемент в БД et c.

Если вы хотите использовать что-то другое, кроме идентификатора, вам понадобится либо просто выполнять запросы вручную (что для родительского / дочернего относительно просто), либо дублировать оболочки свойств и выбирать другое свойство.

...