Так это видимо совсем недавно появилось. 5 лет назад ставил себе сплит кондеры и никакого управления по вайфай не было. Я не стал себе паять всякие малинки, купил обычный китайский ИК передатчик с возможностью подключения к вайфаю, и теперь удаленно управляю. Бонусом еще пару устройств в комнате повесил на этот дешевый ик девайс
Все то же самое. Генерация отдельной командой, вне обычного билда. Только я не коммичу таблицы, так как запуск контейнера и генерация занимают секунд 10. Не критично мне. Как раздуется БД, так, что генерация будет идти в разы дольше, то наверное нужно будет все же складывать jooq классы в репу.
Прикольная конечно штука, но смущает один момент - "it applies all your DDL increments to an in-memory H2 database". По моему опыту не все SQL стейтменты разных БД могут быть отражены в H2 корректно. Сталкивался с таким несколько раз, в эпоху, когда еще testcontainers не были распространены, но в тестах приходилось использовать H2. По памяти, постгресовский тип UUID неправильно будет отражен в моих jooq классах. Вроде INT4, INT8 того же постгреса смапятся чуть по другому. Если у меня в БД еще подключены модули, например гео-типов postgis, то H2 их не поймет. Так что инструмент довольно ограниченный, хотя я могу ошибаться, не пользовался же.
Ну да. Вы сначала создаете бд, таблицы, хранимые запросы и т.д., а потом запускаете генерацию jooq классов, предварительно настроив сам jooq на соединение с БД. В принципе, существование бд для генерации сущностей, а потом компиляции проекта не обязательно. Я себе настроил gradle так, чтобы он во время компиляции сначала поднимал БД в testcontainers, потом флайвейем накатывал миграции и после генерил jooq классы. Это удобно, когда, например, внес изменения в flyway и хочешь сразу эти изменения увидеть во время разработки. Запустил генерацию и получил новые поля в сущностях. Доступная бд при этом не нужна, но при этом получаешь 100% рабочий код, который еще не проверен на реальной базе данных, в отличии от такого же подхода (без рабочей бд) в JPA/ Hibernate, когда написал entity руками, но мог и ошибиться в чем угодно при описании. Такой же механизм у меня работает в CI/CD. Файлы jooq я в репу не кладу, они генерятся на лету.
Но вы говорите, что можно идти от обратного - сначала сущность руками пишем, а в бд за структурой не ходим. Я, если честно, такое не практиковал, да и вообще о таком подходе только сейчас узнал
Уже года 3 знаком с jooq и теперь везде стараюсь использовать его. Поначалу вымораживала концепция «table first», но потом, после некоторой возни с gradle и настройки регенерации сущностей по одной команде стало норм. Даже более удобно, чем в хибере/jpa, где сущности надо все же руками кодить. Конечно не хватает спринговой магии, где простые запросы можно через интерфейсный метод описать, но с другой стороны у jooq в части сложных запросов гибкости в разы больше, да и визуально легче читать.
Один большой минус у jooq - это то что в сложных проектах логика слоя данных течёт во все соседние слои, будь то сервисный слой с БЛ, слой контроллеров. В спринг дата все же слой репозиториев более явно выделен, чем в случае с jooq, где запрос можно писать в любом месте, чем ленивые разработчики и пользуются: «да это же маленький запросик, напишу-ка я его прям в контролере, чо ходить-то за данными далеко». И получается бардак, непонятно что где лежит. Исправляется кодостайлом и дисциплиной, но все же…
Со вторым соглашусь отчасти. Это действительно удобнее, но только в случае если есть необходимость менять БД. Но вот сколько я уже проектов сменил и ни разу не было надобности переключаться с одной БД на другую. И я стараюсь специфичные запросы не писать. И если вдруг такая необходимость возникла бы, то я думаю эта задача очень серьезная, которая потребует внимания всей команды, независимо от того, где прописаны запросы, в конфигах или аннотациях. Потому как потребуется миграция самих данных, а также менять файлы миграции схем и таблиц (всякие флайвей и т.д.), тестирование этого перехода. Короче, сродни пожару.
А с первым все равно не согласен. Но это индивидуально и дело вкуса.
И спасибо за статью, давно такой хорошей информации по хиберу не было. Хотя я сам стараюсь его в проектах не использовать, полюбил jooq, но все же когда-нибудь наверное придется с ним работать.
Как по мне, SQL код в Java коде лучше по двум причинам: во-первых все в одном месте - захотел использовать метод и сразу видишь что он там вытаскивает из бд, и не надо бегать по папкам проекта и искать мапинг этого запроса. Во-вторых - этот ужасный xml. В чем удобство его читать? Столько лишнего всего - схемы, ненужная мне метаинформация, ради одной строчки кода я должен глазами видеть в 3 раза больше бесполезных данных, в течение дня это сильно утомляет. Как вспомню доаннотационные времена спринга или javaee так вздрагиваю.
Ну это да. На старте долго будут настраивать модель закупа. Может эта модель будет нерентабельна для автора. Но в любом случае спрос на вассаби все же есть, я думаю.
Нет, это был Ташкент. Ресторан Тепаньяки. Довольно аутентичное место, при тебе готовят японскую кухню. По вкусу сразу было понятно, что это не крашеный хрен под видом вассаби.
Когда я посещал приличный ресторан японской кухни мне всегда предлагался выбор. Настоящий васаби или хрен мне, а не вассаби. Так что рестораны уверен брать будут, и найдутся люди которые будут заказывать именно вассаби
К сожалению не всегда можно выбрать язык на проекте. А так да, для JVM куча функциональных языков, где такие выкрутасы лепить не надо, все красиво и понятно
У NiFi подробные логи, можно глянуть причину там. Я запускаю в докере, делаю моунт хостовой папки в папку с логами в контейнере и потом анализирую эти логи. Помогло в свое время понять почему падает NiFi. У меня NiFi версии 2
Спасибо большое за библиотеку и примеры. В который раз убеждаюсь, что функциональное программирование в Java - боль и страдания. Код читать очень тяжело. На ревью, попадись такое, я бы орал (но ревьюил, а что делать). Спасибо что есть Котлин, там это все красивее
Я бы выучил джаву. Взаимодействовать, скорее всего, придется. Ну там полазить в кишках библиотек и т.д. А идеоматически Котлин все дальше и дальше от Джавы в плане стиля кода. Я раньше иногда понять не мог на каком языке написан код - на джаве или котлине. Сейчас, если писать в стиле Котлин, как-то уже и совсем не Джава стиль получается.
Во-первых, В Java и Kotlin интерфейсы необязательны. В Kotlin даже классы необязательны (хотя в байткоде обернутся все же в классы функции и переменный объявленые вне классов). Поэтому метод с параметрами необязательно должен стыковаться с каким-то там интерфейсом. Даже если у класса, в котором объявлен метода с параметрами по умолчанию, есть интерфейс - ну и ладно. Я лично так делал и не страдал от нарушения идеологий. Да и не понимаю я, в чем нарушение? Интерфейс - это контракт на структуру и результат, а не на данные или способ подкапотного функционирования этой структуры. Данные как раз предполагаются быть разными в имплементациях, раз уж интерфейс объявлен.
Во-вторых, это плохо иметь 10 параметров в методе. И в Котлине для таких случаев тоже надо использовать билдеры, хоть самому писать, хоть с использованием тех же библиотек из Джавы
У МТС кажется задача - рекламировать китай по максимуму. Прочитав заголовок, но еще не посмотрев автора, предположил чей это блог. И был прав)))
И все статьи в духе «а вот скоро китай вам всем покажет…ууух»
Так это видимо совсем недавно появилось. 5 лет назад ставил себе сплит кондеры и никакого управления по вайфай не было. Я не стал себе паять всякие малинки, купил обычный китайский ИК передатчик с возможностью подключения к вайфаю, и теперь удаленно управляю. Бонусом еще пару устройств в комнате повесил на этот дешевый ик девайс
Все то же самое. Генерация отдельной командой, вне обычного билда. Только я не коммичу таблицы, так как запуск контейнера и генерация занимают секунд 10. Не критично мне. Как раздуется БД, так, что генерация будет идти в разы дольше, то наверное нужно будет все же складывать jooq классы в репу.
Прикольная конечно штука, но смущает один момент - "it applies all your DDL increments to an in-memory H2 database". По моему опыту не все SQL стейтменты разных БД могут быть отражены в H2 корректно. Сталкивался с таким несколько раз, в эпоху, когда еще testcontainers не были распространены, но в тестах приходилось использовать H2. По памяти, постгресовский тип UUID неправильно будет отражен в моих jooq классах. Вроде INT4, INT8 того же постгреса смапятся чуть по другому. Если у меня в БД еще подключены модули, например гео-типов postgis, то H2 их не поймет. Так что инструмент довольно ограниченный, хотя я могу ошибаться, не пользовался же.
А, оказывается внизу уже ответили
Ну да. Вы сначала создаете бд, таблицы, хранимые запросы и т.д., а потом запускаете генерацию jooq классов, предварительно настроив сам jooq на соединение с БД. В принципе, существование бд для генерации сущностей, а потом компиляции проекта не обязательно. Я себе настроил gradle так, чтобы он во время компиляции сначала поднимал БД в testcontainers, потом флайвейем накатывал миграции и после генерил jooq классы. Это удобно, когда, например, внес изменения в flyway и хочешь сразу эти изменения увидеть во время разработки. Запустил генерацию и получил новые поля в сущностях. Доступная бд при этом не нужна, но при этом получаешь 100% рабочий код, который еще не проверен на реальной базе данных, в отличии от такого же подхода (без рабочей бд) в JPA/ Hibernate, когда написал entity руками, но мог и ошибиться в чем угодно при описании. Такой же механизм у меня работает в CI/CD. Файлы jooq я в репу не кладу, они генерятся на лету.
Но вы говорите, что можно идти от обратного - сначала сущность руками пишем, а в бд за структурой не ходим. Я, если честно, такое не практиковал, да и вообще о таком подходе только сейчас узнал
Уже года 3 знаком с jooq и теперь везде стараюсь использовать его. Поначалу вымораживала концепция «table first», но потом, после некоторой возни с gradle и настройки регенерации сущностей по одной команде стало норм. Даже более удобно, чем в хибере/jpa, где сущности надо все же руками кодить. Конечно не хватает спринговой магии, где простые запросы можно через интерфейсный метод описать, но с другой стороны у jooq в части сложных запросов гибкости в разы больше, да и визуально легче читать.
Один большой минус у jooq - это то что в сложных проектах логика слоя данных течёт во все соседние слои, будь то сервисный слой с БЛ, слой контроллеров. В спринг дата все же слой репозиториев более явно выделен, чем в случае с jooq, где запрос можно писать в любом месте, чем ленивые разработчики и пользуются: «да это же маленький запросик, напишу-ка я его прям в контролере, чо ходить-то за данными далеко». И получается бардак, непонятно что где лежит. Исправляется кодостайлом и дисциплиной, но все же…
Со вторым соглашусь отчасти. Это действительно удобнее, но только в случае если есть необходимость менять БД. Но вот сколько я уже проектов сменил и ни разу не было надобности переключаться с одной БД на другую. И я стараюсь специфичные запросы не писать. И если вдруг такая необходимость возникла бы, то я думаю эта задача очень серьезная, которая потребует внимания всей команды, независимо от того, где прописаны запросы, в конфигах или аннотациях. Потому как потребуется миграция самих данных, а также менять файлы миграции схем и таблиц (всякие флайвей и т.д.), тестирование этого перехода. Короче, сродни пожару.
А с первым все равно не согласен. Но это индивидуально и дело вкуса.
И спасибо за статью, давно такой хорошей информации по хиберу не было. Хотя я сам стараюсь его в проектах не использовать, полюбил jooq, но все же когда-нибудь наверное придется с ним работать.
Прежде чем задавать вопрос, статью прочтите, мой коммент относится к разделу «избавляемся от sql в джава коде».
Как по мне, SQL код в Java коде лучше по двум причинам: во-первых все в одном месте - захотел использовать метод и сразу видишь что он там вытаскивает из бд, и не надо бегать по папкам проекта и искать мапинг этого запроса. Во-вторых - этот ужасный xml. В чем удобство его читать? Столько лишнего всего - схемы, ненужная мне метаинформация, ради одной строчки кода я должен глазами видеть в 3 раза больше бесполезных данных, в течение дня это сильно утомляет. Как вспомню доаннотационные времена спринга или javaee так вздрагиваю.
Ну это да. На старте долго будут настраивать модель закупа. Может эта модель будет нерентабельна для автора. Но в любом случае спрос на вассаби все же есть, я думаю.
Нет, это был Ташкент. Ресторан Тепаньяки. Довольно аутентичное место, при тебе готовят японскую кухню. По вкусу сразу было понятно, что это не крашеный хрен под видом вассаби.
Когда я посещал приличный ресторан японской кухни мне всегда предлагался выбор. Настоящий васаби или хрен мне, а не вассаби. Так что рестораны уверен брать будут, и найдутся люди которые будут заказывать именно вассаби
К сожалению не всегда можно выбрать язык на проекте. А так да, для JVM куча функциональных языков, где такие выкрутасы лепить не надо, все красиво и понятно
У NiFi подробные логи, можно глянуть причину там. Я запускаю в докере, делаю моунт хостовой папки в папку с логами в контейнере и потом анализирую эти логи. Помогло в свое время понять почему падает NiFi. У меня NiFi версии 2
Спасибо большое за библиотеку и примеры. В который раз убеждаюсь, что функциональное программирование в Java - боль и страдания. Код читать очень тяжело. На ревью, попадись такое, я бы орал (но ревьюил, а что делать). Спасибо что есть Котлин, там это все красивее
Видимо недавно добавили. У меня толи 17, толи 19 версия джавы. Компиляция в 17 установлена
Какая площадь теплицы для 2х млн тюльпанов?
Я бы выучил джаву. Взаимодействовать, скорее всего, придется. Ну там полазить в кишках библиотек и т.д. А идеоматически Котлин все дальше и дальше от Джавы в плане стиля кода. Я раньше иногда понять не мог на каком языке написан код - на джаве или котлине. Сейчас, если писать в стиле Котлин, как-то уже и совсем не Джава стиль получается.
Как нет? У стримов есть zip метод
Streams.zip(Collection1, Collection2, лямбда).как_всегда_collect(...)
Во-первых, В Java и Kotlin интерфейсы необязательны. В Kotlin даже классы необязательны (хотя в байткоде обернутся все же в классы функции и переменный объявленые вне классов). Поэтому метод с параметрами необязательно должен стыковаться с каким-то там интерфейсом. Даже если у класса, в котором объявлен метода с параметрами по умолчанию, есть интерфейс - ну и ладно. Я лично так делал и не страдал от нарушения идеологий. Да и не понимаю я, в чем нарушение? Интерфейс - это контракт на структуру и результат, а не на данные или способ подкапотного функционирования этой структуры. Данные как раз предполагаются быть разными в имплементациях, раз уж интерфейс объявлен.
Во-вторых, это плохо иметь 10 параметров в методе. И в Котлине для таких случаев тоже надо использовать билдеры, хоть самому писать, хоть с использованием тех же библиотек из Джавы