Я пытаюсь настроить родительские обязанности в приложении (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 были разрешены пользовательские имена свойств, как в предыдущих версиях.
Мне было интересно, сталкивался ли кто-нибудь с этой «проблемой»? или имеет обходной путь, позволяющий моделям продолжать использовать значимые имена и по-прежнему обеспечивать правильную работу родительского контроля.
Я использовал эти простые пользовательские данные в качестве примера, но, конечно же, другие используют другие / значимые имена столбцов, которые страдают от моих. . раздражение?
Приветствуются любые советы / мысли Спасибо