ну кто-то слил свою правку, ты писал новый код к этому полю и ребейзнулся.
тут только тесты и культура ревью
object FilmFields {Читать полностью…
val ID = FILM.ID.nonNullable()
val NAME = FILM.NAME.nonNullable()
val LINK = FILM.LINK
val POSTER_LINK = FILM.POSTER_LINK
val STATE = FILM.STATE.nonNullable()
}
inline fun <T> Field<T>.nonNullable() = convertFrom { it!! }
собственно, это единственная задача жука, я бы и просто на строках все писал, если бы тайпсэйф был возможен
Читать полностью…кстати... можно сделать свой объект со своим набором маппинга, где нужные филды уже будут конвертированы)
Читать полностью…хотя да, тот кто сделал правку должен был бы и маппинг поправить (если мы говорим о кастомном, как в моем случае FilmFields, наборе филдов)
Читать полностью…как только ты это в миграции поменял, ты автоматом поменяешь в конвертации поля
+ тесты
твой сценарий возможен либо в командах с низкой инженерной культурой, либо там, где не ты хозяин бд
ослабляет. код считает что по дефолту все nullable, мы точечно правим и зашиваем в код. какое-то поле меняется на not nullable, генеренный код не меняется, наш ручной маппинг тоже...
Читать полностью…меня только одно расстраивает в таком подходе, как и любом другом для обхода бага - оно ослабляет compile time проверки по сути
Читать полностью…+ дсл в имплементации репозитория связывает твой дата класс и структуру в бд, пропустить не выйдет
Читать полностью…а если структура в ~базе~ таблице поменялась, то это не скажется же если не апдейтить дата класс?
шайтанства нет, мой дата-класс 1 в 1 повторяет структуру, что в бд
просто обхожу баг Эдера