ну они там есть наверно. так как когда я закидываю всё в один пакет всё работает

всё работает! спасибо! не понял особо почему! но спасибо)

А вот еще один вопрос. Вспомнил. Вот в postgresql есть COPY FROM позволяющая из текстового файла записыватьданные в таблицу базы данных. Есть ли такая штука в sqlLite?

Осталось разобраться с этим вопросом)))

может кто нибудь скинуть ссылки на репо хорошей рестфул архитектуры со спрингом гибернейтом и тп

может кто нибудь скинуть ссылки на репо хорошей рестфул архитектуры со спрингом гибернейтом и тп

спринговый петклиник глянь.

Можно линк?)

ну первая же ссылка в гугле https://github.com/spring-projects/spring-petclinic

Спасибо)

Там не только hibernate, так что выбери профиль jpa при билде

Сорри я новенький в спринге и прочем серверном стафе. Если приложение на Спринге то желательно Спринг jpa юзать? Вообще гибернейт через сессии используют?

Сорри я новенький в спринге и прочем серверном стафе. Если приложение на Спринге то желательно Спринг jpa юзать? Вообще гибернейт через сессии используют?

Если тебе нужно быстро сделать rest api со спрингом не думая о производительности и понимании спринга, можешь всё быстро сделать со spring-boot. Начинаешь вот здесь start.spring.io и читаешь какой-то гайд по boot + mvc + security + jpa

А если начну думать о ней?)

Ну, тогда тебя ждет долгий путь.

Разочарования

Спасибо

не юзай jpa

возьми любую умную либу для JDBC

не юзай jpa

Хм, если тебя не заботит производительность и у тебя простой круд, что чаще всего соответсвует ресту, ну и + пагинация, что плохого в jpa?

Вот что ты предложишь для замены? Jooq, mybatis, spring jdbc templates?

да даже JDBCTemplate правда там с динамическими запросами проблема но это все равно лучше чем Hibernate

jooq отличный вариант

да даже JDBCTemplate правда там с динамическими запросами проблема но это все равно лучше чем Hibernate

но это же боль и портянки текста.

Hibernate это еще большая боль

Не стану спорить, но если ты новичек и тебе нужен только круд, и ты не можешь sql, вай нот?

jooq чем не вариант?

фишка в том что ты напишешь код на HIbernate а потом просто не слезешь с него когда начнутся проблемы

фишка в том что ты напишешь код на HIbernate а потом просто не слезешь с него когда начнутся проблемы

Да, и будешь прикручивать всевозможные кеши и страдать.

вот вот

но ещё раз, накидать рест сервис за 20 часов со spring data jpa чем не вариант

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

а потом а можешь отчет на 20 джоинов сделать?

и понеслась

а потом а можешь отчет на 20 джоинов сделать?

тссссс, не говори так, тут же дети.

мне лично mybatis нравится, но там много xml

и с динамическими запросами немного больно.

А вот jooq не трогал, там все так радужно и приятно?

Он же ещё и бабок стоит, если база коммерческая

ну его я не использую работаю с querydsl(похожая штука), не на 100% все радужно но в целом лучше строк в плане динамики и лучше хибернейта в плане понятности

по скорости как jdbc

Не стану спорить, но если ты новичек и тебе нужен только круд, и ты не можешь sql, вай нот?

В чем проблема потратить 20 минут на любой мануал по sql и фигарить на jdbc чистом?

В чем проблема потратить 20 минут на любой мануал по sql и фигарить на jdbc чистом?

за 20 минут —- лучше не надо

В чем проблема потратить 20 минут на любой мануал по sql и фигарить на jdbc чистом?

в обратном мапинге все на сущности, очевидно же

в куче исключений

в целом, работа с jdbc голым довольно больно.

в целом, работа с jdbc голым довольно больно.

при желании там можно быстренько накидать свой враппер

при желании там можно быстренько накидать свой враппер

Есть уже куча готовых.

если уметь готовить хибер - никаких проблем

а вот портянка ждбц - то еще удовольствие

Есть уже куча готовых.

тем более. но новичку лучше накидать :D

в проектах обычно гибридная связка

чем портянка критериа апи лучше?

чем портянка критериа апи лучше?

ААААААААААААААААААААА ? это то что у меня в одном проекте был hql + criteria api

а никак иначе не сделать

в этом прикол

где не вывезли критерии писался hql, где не вывез hql писался натив

если ты еще Spring Data туда замешаешь то у тебя будет Spring Data репозитории HQL и еще критериа

чем портянка критериа апи лучше?

хотя бы читаемостью

кайф

sprind data crud+ dsl query + hql+criteria + jdbc template

???

если ты еще Spring Data туда замешаешь то у тебя будет Spring Data репозитории HQL и еще критериа

Ну, со спринг датой проще, я не встречал что бы туда мещали критерии, максимум hql в @Query

всё-таки с датой очень сильно стараются оставить всё интерфейсами.

именно

а что похардкорней в сервисы

а что похардкорней в сервисы

вот тут я сгорел

ERROR: S client not available

да на уровень сервиса логику работы с БД выносишь а потом не можешь спать по ночам вспоминая ЧТО у тебя там в сервисе

да на уровень сервиса логику работы с БД выносишь а потом не можешь спать по ночам вспоминая ЧТО у тебя там в сервисе

и ещё транзакция в сервисе открывается

транзакция на уровне сервиса это норм

мне не нравится

и лейзи тоже не нравится

транзакция на уровне сервиса - классика

сервис рулит несколькими источниками

какие проблемы?

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

в бд запись прошла а в люсин нет

стоит ли тебя брейкать всю транзакцию?

нужно по идее совместную транзакцию мутить

в таком случае

да ролбекать

если ты считаешь такое поведение не правильным - роллбэк

по эксепшену

Вот а что я чаще всего в проекте видел, это анотация спринговая @Transactional или как там над всем методом

правильно, не вручную рулить же транзакциями

мне и в ручную неплохо.

мне и в ручную неплохо.

тебя тоже смущает магия ?

Да какая там магия

просто тебе нужно взять имя твоей аннотации

найти beanpostprocessor который её обрабатывает

найти метод ролбека

и посмотреть

?

угу

мне и в ручную неплохо.

ты вручную рулил транзакциями на работе?

а что коллеги говорили?

угу

вот по этой причине мне нравятся фреймворки в кторых я могу ткнуть на метод и посмотреть что он делает.

ты вручную рулил транзакциями на работе?

В одном рулили, но это было давно и неправда