💭П
Мне интересна статистика. Спасибо.
Size: a a a
2019 November 04
Ld
Свой вариант, это 0 мониторов?
SS
Через скринридер человек работает, нехорошо шутить над инвалидами
2019 November 05
Ld
Не подумал, простите
2019 November 24
SS
Вообще, что думаете про jOOQ и прочие репозитории этой орги https://github.com/jOOQ ?
2019 November 26
RK
jOOQ достаточно часто рекомендуют для работы с SQL, из того что я видел в Scala RU и Kotlin RU чатиках
RK
Думаю, скалистам особенно зашло за счёт type-safety
2019 November 28
RM
Вообще, что думаете про jOOQ и прочие репозитории этой орги https://github.com/jOOQ ?
ctx.select(
ACTOR.FIRSTNAME,
ACTOR.LASTNAME,
count().as("Total"),
count().filterWhere(LANGUAGE.NAME.eq("English")).as("English"),
count().filterWhere(LANGUAGE.NAME.eq("German")).as("German"),
min(FILM.RELEASE_YEAR),
max(FILM.RELEASE_YEAR))
.from(ACTOR)
.join(FILM_ACTOR).on(ACTOR.ACTORID.eq(FILM_ACTOR.ACTORS_ACTORID))
.join(FILM).on(FILM.FILMID.eq(FILM_ACTOR.FILMS_FILMID))
.join(LANGUAGE).on(FILM.LANGUAGE_LANGUAGEID.eq(LANGUAGE.LANGUAGEID))
.groupBy(
ACTOR.ACTORID,
ACTOR.FIRSTNAME,
ACTOR.LASTNAME)
.orderBy(ACTOR.FIRSTNAME, ACTOR.LASTNAME, ACTOR.ACTORID)
.fetch()
вот это вот откровенное дно. что JPA, что JOOQ одна херня
RM
есть дждбс темплейтс + ликвибейз, а большего не надо. все эти попытки втащить очередной DSL в язык, который плохо с ними дружит - путь в бесконечный дебаг, боль, содомию.
а тут еще и запрос просто так в исполнятель запросов не скопипастишь.
а тут еще и запрос просто так в исполнятель запросов не скопипастишь.
RM
был бы в джава репл нормальный - можно было бы стерпеть и из репла тестить свои запросы
RM
представляю прям, как наверное весело тут еще и с константами развлекаться, в большом проекте.
RM
в общем это еще один стул, в бесконченых попытках впиать не впихуемое
RM
SQL was never meant to be anything other than... SQL!
лол, сказали ребята и напилили своих классиков абстрагирующих SQL
SK
ctx.select(
ACTOR.FIRSTNAME,
ACTOR.LASTNAME,
count().as("Total"),
count().filterWhere(LANGUAGE.NAME.eq("English")).as("English"),
count().filterWhere(LANGUAGE.NAME.eq("German")).as("German"),
min(FILM.RELEASE_YEAR),
max(FILM.RELEASE_YEAR))
.from(ACTOR)
.join(FILM_ACTOR).on(ACTOR.ACTORID.eq(FILM_ACTOR.ACTORS_ACTORID))
.join(FILM).on(FILM.FILMID.eq(FILM_ACTOR.FILMS_FILMID))
.join(LANGUAGE).on(FILM.LANGUAGE_LANGUAGEID.eq(LANGUAGE.LANGUAGEID))
.groupBy(
ACTOR.ACTORID,
ACTOR.FIRSTNAME,
ACTOR.LASTNAME)
.orderBy(ACTOR.FIRSTNAME, ACTOR.LASTNAME, ACTOR.ACTORID)
.fetch()
вот это вот откровенное дно. что JPA, что JOOQ одна херня
Да ладно, JOOq гибкий, если не нравится такой синтакс, можно как в JDBC templates — просто параметризированной строкой запрос передать. Зато не спринг :)
RM
аргумент века:
Зато не спринг
SK
аргумент века:
Зато не спринг
Это шутка, че ты)
RM
зачем тащить хз что, если итак есть темплейтс?
SK
ctx.select(
ACTOR.FIRSTNAME,
ACTOR.LASTNAME,
count().as("Total"),
count().filterWhere(LANGUAGE.NAME.eq("English")).as("English"),
count().filterWhere(LANGUAGE.NAME.eq("German")).as("German"),
min(FILM.RELEASE_YEAR),
max(FILM.RELEASE_YEAR))
.from(ACTOR)
.join(FILM_ACTOR).on(ACTOR.ACTORID.eq(FILM_ACTOR.ACTORS_ACTORID))
.join(FILM).on(FILM.FILMID.eq(FILM_ACTOR.FILMS_FILMID))
.join(LANGUAGE).on(FILM.LANGUAGE_LANGUAGEID.eq(LANGUAGE.LANGUAGEID))
.groupBy(
ACTOR.ACTORID,
ACTOR.FIRSTNAME,
ACTOR.LASTNAME)
.orderBy(ACTOR.FIRSTNAME, ACTOR.LASTNAME, ACTOR.ACTORID)
.fetch()
вот это вот откровенное дно. что JPA, что JOOQ одна херня
Ну и справедливости ради, запрос в твоем примере сам по себе уже многоэтажный, и строкой в темплейтах смотрелся бы так же говенно. А с JOOqом он хотя бы более менее безопасней. Скосячишь где нить в запросе — билд повалит.
OK
был бы в джава репл нормальный - можно было бы стерпеть и из репла тестить свои запросы
Тесты же есть для отладки, в скала есть репл, но в таких целях не применял.