pro.jvm

23 Dec 2024 16:14

а тесты поймали бы ошибку на вставке null

pro.jvm

23 Dec 2024 16:13

хотя да, тот кто сделал правку должен был бы и маппинг поправить (если мы говорим о кастомном, как в моем случае FilmFields, наборе филдов)

pro.jvm

23 Dec 2024 16:11

как только ты это в миграции поменял, ты автоматом поменяешь в конвертации поля

+ тесты

твой сценарий возможен либо в командах с низкой инженерной культурой, либо там, где не ты хозяин бд

pro.jvm

23 Dec 2024 16:09

ослабляет. код считает что по дефолту все nullable, мы точечно правим и зашиваем в код. какое-то поле меняется на not nullable, генеренный код не меняется, наш ручной маппинг тоже...

pro.jvm

23 Dec 2024 16:07

но ведь не ослабляет, мы просто фиксим баг ленивца эдера

pro.jvm

23 Dec 2024 16:04

меня только одно расстраивает в таком подходе, как и любом другом для обхода бага - оно ослабляет compile time проверки по сути

pro.jvm

23 Dec 2024 16:00

её писать во всех селектах тогда

pro.jvm

23 Dec 2024 15:59

и потом в select использовать FilmFields

pro.jvm

23 Dec 2024 15:59

А нельзя unchecked cast в одном месте, чтобы не писать кучу бойлер-плейта?

pro.jvm

23 Dec 2024 15:58

+ дсл в имплементации репозитория связывает твой дата класс и структуру в бд, пропустить не выйдет

pro.jvm

23 Dec 2024 15:57

а если структура в ~базе~ таблице поменялась, то это не скажется же если не апдейтить дата класс?

pro.jvm

23 Dec 2024 15:55

у меня это кастомный data class User, если ты про это

pro.jvm

23 Dec 2024 15:53

какие то чудеса и рождественская магия между 22.0.5 и 25.0.5

pro.jvm

23 Dec 2024 15:52

шайтанства нет, мой дата-класс 1 в 1 повторяет структуру, что в бд
просто обхожу баг Эдера

pro.jvm

23 Dec 2024 15:51

override fun findByKeycloakId(keycloakId: String): User? {
    return db.select(
        USERS.ID.convertFrom { it!! },
        USERS.KEYCLOAK_ID.convertFrom { it!! },
        USERS.EMAIL.convertFrom { it!! },
        USERS.USERNAME.convertFrom { it!! },
        USERS.FIRST_NAME,
        USERS.LAST_NAME,
        USERS.CREATED_AT.convertFrom { it!! },
        USERS.UPDATED_AT
    ).from(USERS)
        .where(USERS.KEYCLOAK_ID.eq(keycloakId))
        .fetchOne(Records.mapping(::User))
}

pro.jvm

23 Dec 2024 16:14

да и его мр не должен был быть слит без этого

pro.jvm

23 Dec 2024 16:12

ну кто-то слил свою правку, ты писал новый код к этому полю и ребейзнулся.

тут только тесты и культура ревью

pro.jvm

23 Dec 2024 16:10

сборка будет зеленой. а если тестов на это место нет - поймаем только в рантайм

pro.jvm

23 Dec 2024 16:07

который закрывает ишью на гитхабе, а у народа наллабл в кодгене

pro.jvm

23 Dec 2024 16:05

как и маппер с рефлексией, там вообще неявно это делается

pro.jvm

23 Dec 2024 16:01

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

pro.jvm

23 Dec 2024 16:00

+ можно просто экстеншен функцию сделать

pro.jvm

23 Dec 2024 15:59

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!! }

pro.jvm

23 Dec 2024 15:59

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

pro.jvm

23 Dec 2024 15:58

упадет компиляция и тесты, править все придется в любом случае

pro.jvm

23 Dec 2024 15:56

да даже неохота подсвечивать. утро вечера мудренее. порешаю завтра

pro.jvm

23 Dec 2024 15:53

кстати... можно сделать свой объект со своим набором маппинга, где нужные филды уже будут конвертированы)

pro.jvm

23 Dec 2024 15:52

эх. этот key от которого сегодня полыхнул мой cloak

pro.jvm

23 Dec 2024 15:51

так и понял

некрасивое шайтанство, я лучше рефлексией

pro.jvm

23 Dec 2024 15:49

но благодаря .convertFrom { it!! } это инлайном можно конвертнуть