ну кто-то слил свою правку, ты писал новый код к этому полю и ребейзнулся.
тут только тесты и культура ревью
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 проверки по сути
Читать полностью…+ дсл в имплементации репозитория связывает твой дата класс и структуру в бд, пропустить не выйдет
Читать полностью…а если структура в ~базе~ таблице поменялась, то это не скажется же если не апдейтить дата класс?