RR
спасибо, тоже так думаю
Size: a a a
2021 June 16
T
альтернатива - работать с реляционной базой как чисто с реляционной базой, через какой-то простой и прозрачный слой кода, без ненужной магии и абстракций object relational mapping
AD
Kotlin.exposed тоже интересный.
jOOQ хорош в том, что компиляция упадёт, если схема изменилась и код к ней не готов
jOOQ хорош в том, что компиляция упадёт, если схема изменилась и код к ней не готов
T
jOOQ не использовал потому что яву бросил лет 10 назад, но он выглядит годно, typesafe обёртка без магии
AR
jooq хорош чтобы читать, hiber чтобы писать
T
hiber не нужен, jdbctemplate пишет не хуже
AR
писать native sql, ну такое
T
и это если ещё отодвинуть мнение что реляционные базы не масштабируются и для чего-то кроме отчётов не особо годятся
ET
AD
Падажжи,
1. В холивар встревать не хочу, чисто имхо
2. ОRM должен как-то определять, изменилось ентити или нет: это накладные ресурсы (либо версию трекать, либо модифаид)
3. Я лично ловил, когда делаем запрос in на пару десятков тыщ, а хибер пытается это кешировать ( и настройками это не решалось), сервис падал с ООМ
1. В холивар встревать не хочу, чисто имхо
2. ОRM должен как-то определять, изменилось ентити или нет: это накладные ресурсы (либо версию трекать, либо модифаид)
3. Я лично ловил, когда делаем запрос in на пару десятков тыщ, а хибер пытается это кешировать ( и настройками это не решалось), сервис падал с ООМ
T
вот это и есть ё$$$ная магия
во-первых это стоит перформанса немало (то же самое без хибернейта быстрее в разы)
во-вторых абсолютно непрозрачно, что там реально происходит в недрах ORM, что и как кешируется
например если это поле блоб - то он по нескольку раз (де) сериализуется, местами чтобы просто посмотреть, не изменился ли он
ну и все эти lazy load, когда вызвал get на магическом ORM объекте и _внезапно_ получил запрос вытаскивающий десять тыщ сущностей из базы
не троньте каку, это отрыжка EJB из нулевых
EJB все забыли, а ORM почему-то нет
во-первых это стоит перформанса немало (то же самое без хибернейта быстрее в разы)
во-вторых абсолютно непрозрачно, что там реально происходит в недрах ORM, что и как кешируется
например если это поле блоб - то он по нескольку раз (де) сериализуется, местами чтобы просто посмотреть, не изменился ли он
ну и все эти lazy load, когда вызвал get на магическом ORM объекте и _внезапно_ получил запрос вытаскивающий десять тыщ сущностей из базы
не троньте каку, это отрыжка EJB из нулевых
EJB все забыли, а ORM почему-то нет
AD
Яростно плюсую
И
Не забыли потому что, когда хромает знание sql с орм легче стартануть проект. Кажущееся быстродоступное простое решение.
AD
Вот прототипирование-вполне.
В то же время, когда хромает знание SQL, но сотрудник при этом жонглирует Embeddable entity и варьирует наследование.. выглядит, скорее как бомба отложенного срабатывания
В то же время, когда хромает знание SQL, но сотрудник при этом жонглирует Embeddable entity и варьирует наследование.. выглядит, скорее как бомба отложенного срабатывания
И
Наши мананагеры вынуждают на этом прототипе строить mvp и конечный продукт
И
Такое себе
И
Но да от целей зависит. Если это поделка локальная с 1000 внутриофисных юзерей- почему бы и не орм
T
если поделка то пофиг на чём писать, хоть на руби )
SP
сегодня прототип завтра продакшен)