жизнь без jpa

http://slick.lightbend.com/

о, это я со скалей пробовал.

та еще жесть :)

Спокойно можно переезжать на jdbc-template и не париться. Разница в sql-диалектах решается spring профилями, row-mapper пишутся легко и просто в java8. А вообще есть крайне кошерный spring-data-jpa, там вам и транзакции, и jpql, и native-sql. Мешать в одном проекте разные фреймворки работы с бд крайне дурная идея, не стоит этого делать вообще и никогда кроме того случая, когда ты гуру и точно знаешь что происходит с твоими транзакциями.

Спокойно можно переезжать на jdbc-template и не париться.

Поддерживаю. Сам так сделал в своем пет-проекте и пока ни разу не пожалел.

Так все верно, берешь jooq и jdbc-template и начинаешь жить как белый человек.

с jpa я не работал по-сути. Про jOOQ могу сказать. Я люблю писать БД в БД-редакторе. Сейчас это PgAdmin. Создаю таблицы в нем, и не имею ни малейшего желания переписывать все в Entity. Вот jOOQ все генерит сам для меня. Настроил один раз, и делаешь каждый раз maven generate-source или maven compile. Запросы через него проще писать. Получается все ООП:

    public static Result<Record> getBases1cFromActiveExchangeSettings(DSLContext dslContext) {

        return dslContext
                .select(BASES_1C.fields())
                .from(BASES_1C)
                .innerJoin(EXCHANGE_1C_WMS)
                .on(EXCHANGE_1C_WMS.BASE_1C_UT_ID.eq(BASES_1C.ID)
                        .and(EXCHANGE_1C_WMS.ACTIVE)
                )
                .union(
                        dslContext
                        .select(BASES_1C.fields())
                        .from(BASES_1C)
                        .innerJoin(EXCHANGE_1C_WMS)
                        .on(EXCHANGE_1C_WMS.BASE_1C_WMS_ID.eq(BASES_1C.ID)
                                .and(EXCHANGE_1C_WMS.ACTIVE)
                        )
                )
                .fetch();

    }

И в случае, если при очередном обновлении я что-то переименую, то все будет видно в проекте сразу. Проект не скомпилится. Ждать рантайм-ошибок не приходится. Ну и при написании запросов пользовать intellisence для полей - это же удобней, нежели plain-text.

Ты... Ты знаешь про существование liquibase? Не нужно делать миграции средствами jpa или jooq, просто поверь, не нужно...

И вроде как у hibernate была приблуда для генерации entity по схеме бд, помню использовал maven плагин какой то пару лет назад... Но по мне это тоже зло, поля в бд могу называться как угодно, а через аннотации можно сделать маппинг поле бд - поле в entity.

Я сейчас jpa только для простых ненагруженных приложений использую. Где даже схему бд описываю через энтити, а не пишу sql вручную. Максимально быстро можно набросать объекты и тесты.

1. чем плохо живется в jpa?

Некоторые задачи решаются сложно. Легко сделать тормоза, которые потом убирать очень сложно.

но писать весь этот ваш sql и alter table к нему. в этом тоже мало радости.

SQL писать несложно. А радость будешь от амфетаминов испытывать, на работе надо работу работать.

3. вот эти фокусы типа jooq. какие есть еще? чем оно лучше?

JDBC. Чем ближе к SQL, тем лучше. Ещё лучше был бы нативный интерфейс к конкретной БД, максимально близкий к протоколу, но в жаве я такого не видел.

в целом: если переезжать, то куда? и надо ли?

Переезжать куда-то почти всегда плохая идея. Раньше надо было думать.

нет, не знаю. спасибо, прочитаю. но у меня как раз и нет управления миграциями. вручную все.

ок. с помощью liquibase можно писать migration и управлять ими. ок. а можно мне скрипты миграции получить из самой БД? чтоб я создал таблицу в БД, что-то запустил, а оно мне - скрипт миграции. а?

Ну как обычно, на знакомой технологии шишек уже набил, все косяки уже знаешь и понимаешь почему она - говно. Приходишь на сайт алтернативы - а там всё радостно и замечательно. И вот ты радостно тянешь её в прект и радуешься, пока не начинают лезть косяки. И вот ты уже обколотил все острые углы у новой технологии и обоснованно считаешь её говном. И снова идешь на сайт какой-нибудь ещё альтернативы...

Хотя есть просто категория людей, которые увидев приоткрытую дверь бросаются к ней, на ходу расстегивая ширинку.

При живой миграции с одной базы на другую проблемы самой миграции на стороне базы перевесят весь этот бред лёгкости миграции средствами абстракции JPA.

Да и не бывает миграций. А там, где бывают, то это проекты на многие человекомесяцы.

Получается все ООП

в jpa есть criteria builder, те же яйца, только не сказать что всегда удобно.

JDBC. Чем ближе к SQL, тем лучше.

много ручной работы, а если много классов и таблиц, то легко накосячить.

и вообще, кодогенерация --- это вроде хорошо?

много ручной работы, а если много классов и таблиц, то легко накосячить.

Чтобы не накосячить, можно писать интеграционные тесты. Общий код выносить с помощью того же JDBCTemplate или рукописного аналога.

и вообще, кодогенерация --- это вроде хорошо?

Не всегда. Минус в том, что ты не видишь сгенерированного кода, но должен всегда помнить про то, что он есть и хорошо представлять, что он делает. В этом вся проблема Hibernate и заключается — люди просто забывают, что там куча кода и думают, что там чёрная магия, которая всем делает хорошо. А Hibernate это очень сложная в применении технология, как раз поэтому: надо всегда понимать, в какой SQL разворачивается запрос, как используются Hibernate-кеши, что лежит в сессии и тд. Если это всё есть у всех разработчиков, можно и через Hibernate. Но через JDBC почти всегда получается в итоге лучше.

Вообще не уверен что существует такое решение. Вообще эти скрипты очень простые и пишутся один раз, потом только новые добавляются. Если у тебя уже бд на +50 таблиц и нет миграций - сам виноват)

Создал таблицу в PgAdmin, потом щелкнул по ней левой кнопкой - внизу высветится голый SQL. Скопировал в liquibase.

вот это хотелось бы автоматизировать.

Из-за шрифтов сначала подумал про IPA. Долго думал, чем тебе эль-то не угодил.

поставил flywaydb