чтобы код писать и джавистов унижать, а что?

вы же с джавистами одни и те же круды пишите)

ну че ты начинаешь, нормально же общались

я имел в виду, бэкенды на ней пишите?

да, конечно

Они бы и фронтенд на ней писали.

да, это жёстко

А типа потому что сбертех. Сразу не понял.

Ты опять не понял. Я имел ввиду, что есть такой писатель "Франц Кафка" :)

Ты опять не понял. Я имел ввиду, что есть такой писатель "Франц Кафка" :)

В честь которого, кстати, названа эта разработка :)

В честь которого, кстати, названа эта разработка :)

Я так и думал

Они бы и фронтенд на ней писали.

так пишут же, там в одном из подразделений ZK используется, катаешь на жабке и xml, а оно фронт тебе генерит

У меня ZK ассоциируется только с zookeeper, что это такое?

У меня ZK ассоциируется только с zookeeper, что это такое?

+

это монстроузная штука аналог GWT, но родом с тайваня.

вот эти ребята https://www.zkoss.org/

ого, жестко, не слышал про такое даже

Откуда они взяли что они "Leading"

Впервые вижу данный продукт и он попахивает)

Откуда они взяли что они "Leading"

Так звучит мощнее.

Откуда они взяли что они "Leading"

это для центителей энтерпрайзного стиля. нельзя просто так взять и выкатить продукт, он должен быть обязательно лидинг или еще лучше - энтерпрайз солюшн корпортивного бизнес уровня. чем больше бессмысленных слов, тем лучше и НАДЕЖНЕЕ

это для центителей энтерпрайзного стиля. нельзя просто так взять и выкатить продукт, он должен быть обязательно лидинг или еще лучше - энтерпрайз солюшн корпортивного бизнес уровня. чем больше бессмысленных слов, тем лучше и НАДЕЖНЕЕ

Маркетинговый ход мыслей понятен) видимо просто нет Enterprise Web Frameworков, есть просто Web Framework - вот и получается что они leading) только странно что они на поисковой выдаче гугла не первые по запросу: enterprise java web framework. Зато по запросу leading enterprise Java web framework они уже первые..

Но все эти танцы с бубном вокруг фронта до добра не доведут)

фронт уже никак не спасти, это потерянное направление. исполинский шалаш из костылей, перемотанный изолентой, который еще и горит

фронт уже никак не спасти, это потерянное направление. исполинский шалаш из костылей, перемотанный изолентой, который еще и горит

в котором сидит хипстер с подвёрнутыми штанами в клетчатой рубашке с бородой, вейпящий и попивающий смузи

вот эти ребята https://www.zkoss.org/

Блэт, у меня на проекте тоже это говно, навязанное фреймворком

Хорошо, трогать не приходится

Кто-нибудь деплоил Spring Boot проект в ServiceMix/Karaf?

запилил два раздельных репозитория в spring batch и развел часть джоб на один, часть на второй

экая наркомания

экая наркомания

Зачем?

Зачем?

потому что по дефолту батч сериализует всю метадату джобы и пишет в БД, там поле CLOB

Всё бы ничего, но на стыке Спринга и Оракла - CLOB дало проблемы

вначале там ваще класс каст эксепшн

если не подключить LobHandler кастомный

спринг деклалирует, что оно полностью совместимо с Ораклом 10+

но по факту - оно хоть и создает CLOB объект - пытается его проинсертить в режиме строки

а у Оракла на это дело ограничение 32к байт

а если больше, то там это иначе пишется

то есть, похоже баг в спринг батче в этих их CLOB обработчиках

то есть джоба отрабатывает, а потом на этапе апдейта инфы о степе - всё разваливается нахер

Поэтому запилил второй репозиторий, который ин мемори, и эту джобу на него перевел

Вот я не уверен что blob clob и прочее г-но больших размеров на самом деле нужно, в реляционных бд.

если оно есть, значит кому-то оно нужно

Вот я не уверен что blob clob и прочее г-но больших размеров на самом деле нужно, в реляционных бд.

у ораклины это одна и главных отличительных фич - разные операции с xml. она типа заточена под подобные извращения - работа с xml в бд типа кладешь гиганские xml клобы и делаешь всякие непотребства с ними

да

но класть их надо правильно

а не как спринг

а так - это вечный спор

я, помнится, пилил документооборот на C# на одной платформе

так там по дефолту все файлы клались в БД

и вытеснение на хранилище - это была опция, но не дефолт

как столкнулся с этой задаче, проще всего оказалось как в доке, на голом jdbc без всяким там спрингов и ормов

как столкнулся с этой задаче, проще всего оказалось как в доке, на голом jdbc без всяким там спрингов и ормов

все БД-специфичное так проще, согласен

а мне вот пришлось "разводить потоки"

я вначале всё в ин-мемори сложил

пришёл тимлид и начал рассказывать про то, что есть важные джобы, статус которых хочется мониторить в БД

пришлось творить наркоманию

пришлось творить наркоманию

Лучше стать самому тимлидом.

ERROR: S client not available

Лучше стать самому тимлидом.

вот никакого желания %( я технарь, а не менеджер

у ораклины это одна и главных отличительных фич - разные операции с xml. она типа заточена под подобные извращения - работа с xml в бд типа кладешь гиганские xml клобы и делаешь всякие непотребства с ними

Да в xmltype можно по xpath селекты писать прям из поля. И ограничения то же. Было время извращался в pl/sql с этим делом

Но clob!=xmltype

у спринг батча именно clob там

Странно. Не испытывал проблем с clob пользуясь дефолтным LobHandler в oracle. Правда я это не в батче использовал а просто в JdbcTemplate - он нормально маппит оракловые типы

В батче как-то извратились по этому делу?)

Но clob!=xmltype

Вот xmltype он не переваривал. У нас везде были обертки из процедур которые xmltype в clob переводили

В батче как-то извратились по этому делу?)

хрен его знает, приделал LobHandler - кастоваться стало хорошо, на маленьких объемах - тоже хорошо

а вот 32к+ - всё, упали

Но clob!=xmltype

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

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

Ясно)

А у jpa entity класса обязательно указывать equals & hashcode? jpa это вообще использует? есть же @Id

А у jpa entity класса обязательно указывать equals & hashcode? jpa это вообще использует? есть же @Id

Ну если только в бд писать, то не надо ничего переопределять, если тебе нужно где то хеш считать и по нему доставать, то конечно

хэш я, пожалуй, считаю, когда делаю groupBy по полям.

Разве ты когда достаёшь из базы, то джава что то через себя пропускает?

Ммм, ну если Set'ы есть - тогда будут проблемы, если не переопределены

groupBy вроде же чисто sql штука

Или я не знаю про жпа

Могу ошибаться

А

Ну если сеты то да

Может быть где то @ManyToMany, или какие то другие аннотации

И над Set полем класса указываешь эти аннотации

Соответственно если элементы сета это твои типы, то да, надо переопределять

Да ладно. Я ничего не понимаю и мне лень разбираться. нагенерю везде этих equals & hashcode

Доброго времени суток! Коллеги, подскажите, пожалуйста, как архитектурно коректнее: есть форма регистрации, данные из которой в реквесте получает контроллер. Вопрос: где коректно создавать юзера на основании этих данных - в контроллере или передавать реквест на сервис, и создавать юзера там?

У меня дто пользователя летит в сервисный слой

Я бы в сервис отдавал

Я бы в сервис отдавал

спасибо, тоже этот вариант мне больше импонирует