и что-то появится только при вызове геттера

можно попробовать @Valid повесить на геттер

если позволяет

разве @Valid не вызывает Getter для проверки?

и для связи 1 к 1 можно юзать жадную стратегию

она по дефолту такая

разве @Valid не вызывает Getter для проверки?

не в курсе

по идее он должен геттер юзать для своих целей но в принципе совет ясен попробую может пойдет, а то EAGER совсем плохо

попробую на геттер повесить

http://stackoverflow.com/questions/7774413/bean-validation-through-jpa-relationships

немного проливает свет

http://forum.spring.io/forum/spring-projects/web/82890-cascade-validation-using-valid-annotation

человек вроде подсказал тоже, что и я

отпишись потом, что с геттером

я не уточнил, Hibernate валидация проходит нормально, не проходит Spring валидация(которую я юзаю в методе в контроллере) т.е. по сути валидация у меня проходит два раза, первый раз на этапе биндинга данных с клиента и второй раз сам HIbernate валидируется данные при обновлении в БД Spring валидация запускается public void edit(@Valid @ModelAttribute Project project, BindingResult bindingResult) {...}

Есть смысл хешировать хеш от пароля пользователя, чтобы хранить его БД. Или от количества хеширований безопасность не улучшится?

на геттер не помог вариант

только смена на EAGER помогает

хотя понятное дело плохая идея биндить данные с клиента сразу на JPA Entity

но вначале казалось хорошей :D

вариант какой друг

юзать жадную стратегию, тогда будет не прокси грузится, а реальный объект

и посмотри паттерн DTO - транспортные объекты

делай валидацию на них в контроллере

не управляй напрямую доменными сущностями

ох уж этот data transfer object

ну тут без него плоховато

я понял сейчас мы переходим на DTO а эта проблема осталась я запомнил так сказать, сейчас мы юзаем DTO + MapStruct

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

по первому вопросу вот примерный код: @Transactional public Project save(Project project) { project.setDate(new Date()); Project previous = repository.findOne(project.getId()); ... return repository.save(project); } объект previous нужен для бизнесовой логики, сейчас мы делаем entityManager.detach(project) в первой строке кода

иначе на repository.findOne(project.getId()) Hibernate делает UPDATE

а почему бы repository.findOne не вынести вперед?

предполагается что объект может быть уже изменен за пределами вызова этого метода, я сделал project.setDate(new Date()); что бы показать что он отличается от того что в БД

ну странно как-то

типичный метод апдейта

обычно сначала сущность достают по айди

я так понимаю, там где у тебя точечки - переливашка свойства через сеттеры, да?)

там логика: project это "типо" новый объект а previous старый(тот что в БД) на project данные забиндены с клиента(т.е. они отличаются от previous) возможны проверки например у проекта изменился статус(был "в работе" стал "завершено") в таком случае нужно другие свойства проекта изменить, короче логика

а флуш где происходит?

в этих проверках?

эээ, ребят, как вы обзываете association tables для many-to-many, когда названия таблиц у нас что-то типа POINT и POINT_TYPE ?

типо того, хибер так же генерит

нет, как раз в этом и заключается вопрос, сейчас у нас стоит FlushType AUTOFLUSH, т.е. хибернейте сам может сделать flush когда хочет во время транзакции и 100% делает на commit(я так понимаю) фактически метод repository.save делает entityManager.merge или entityManager.persist

сделайте FlushModeType.COMMIT

и все разрешится

"org.hibernate.flushMode" - вроде такая пропертя у хибера

я нихрена не понял))

ну мы так и думаем либо передавать на сохранение DTO объект который по сути вне контекста либо перейти на FlushModeType.COMMIT

переходите

а вы юзаете какой тип?

это же логично, что коммит и флаш будет по окончанию работы @Transactional

просто разрабы хибернейт не советуют менять FlushModeType

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

не видел такого

я где то читал в доках у них

у нас коммит по выходу из метода

понял

флеш мод то можно менять) только в данном контексте я не понял нафига)

а вот уровень изоляции, да, не советуют)

от флеш мода зависит когда данные попадают в БД(внутри транзакции), например ALWAYS сливает данные при ЛЮБОМ селекте в той же транзакции, AUTOFLUSH сливает данные когда хибернейт сам захочет, COMMIT по коммиту

вообще-то флеш меняет стейт обьекта внутри хибера) причем тут коммит)

.flush?

да)

Synchronize the persistence context to the underlying database.

в доках

.flush сливает данные как раз

а вот persist и merge в контекст заливают данные

ERROR: S client not available

.flush сливает в БД

ща)))

я таки открою апи))

а ну да...внутри транзакции сливает)

правда данные будут не видны)

поэтому стратегию надо поменять

данные будут видны

в этой транзакции

а если READ_UNCOMMITED то не только

ну так ты изоляцию меняешь) ессесно)

но тут может быть беда)

Паш, в общем коммит мод норм решение?

начнешь инкрементить ченить и привет)

оцени, пожалуйста

норм решение для чего?)

чтобы не сливалось все сразу

а только после коммита - выхода из метода

да вполне себе норм))

Заменить OneToOne на Manytoone не получиться?

а кто-нибудь lwjgl 3 на маке пробовал юзать?

я месяца 2 назад запускал их пример, думал, что придётся ноут под кондиционер ставить

а кто-нибудь lwjgl 3 на маке пробовал юзать?

я

и писала из под мака

и как, не греется что дурной?

нет

хочу просто попробовать еще раз запустить, так думаю, стоит ли :) тогда они 3й вроде только-только зарелизили, когда пробовал запустить

ограничивай фпс

он там когда просто окно пустое запускаешь 4.5к может быть

о, попробую

спасибо :)

да пока не за что

там еще есть проблемы при использовании awt