Здравствуйте, GreenTea, Вы писали:

GT>Здравствуйте, andreyzz, Вы писали:

GT>>>Тут не понял, вы пытаетесь сохранить parentDataList, и в то же время в геттере сущности какая то логика, по вытаскиванию списка извне.
GT>>>Дам вам совет, никакой логики в сущностях модели. Обычный гет и сет. Иначе намучаетесь с хибернетом, даже если на первый взгляд покажется что проблемм нет.
A>>тут как раз все нормально ( не зря же я целый день гугл и форумы буржуинские читал) при условии, тчо геттер\сеттер акромя как hibernate никем не используется ( в моем случае я их package local сделал для этого) в моем нормальном коде я такие интересные моменты ссылками с объяснениями комментирую, если там шибко много и умно расписывают. тут банально — если есть логика, то сам не трогай! иначе будет dirty entity

GT>Не понял объяснения.. Хибренет работает в обход этого геттера напрямую с полем? Если нет — то будут проблемы.

A>>как на выходе своего parentService получить цельный экзепляр Parent с востановленным dataHolder внутри него ...
GT>

GT>public void setAccountCookieList(Set<ParentData> parentDataList) {
да тут опечатка setParentDataList  - соотв-но при @Access(value = AccessType.PROPERTY) доступ к полю будет фактически приводить к вызову геттера\сеттера, т.е. само поле по сути не нужно мне.
GT>    assert this.parentDataList != null;
GT>    this.parentDataList.addAll(parentDataList);
GT>    dataHolder.addAll(parentDataList)
GT>  }
GT>

GT>А кто будет вызывать этот сеттер?
GT>Может все таки должно быть setParentDataList? Хотя судя по логике внутри — нет.. Вообще каша какая-то. Я этот код не понимаю
GT>Можете описать требования словами без кода? Т.к. у меня подозрение что вы все реализовали.. кхм, не совсем правильно с архитектурной точки зрения.
попробую описать в целом.
есть система управления "водопровод". в ней есть датчики, эти датчики необходимо периодически регистироравать в системе\ удалять оттуда. обрабатывать данные, и пересылать обработанные данные 3му лицу.
сразу оговорюсь, что эта система уже имеет реализацию на perl но в 21веке это уже некошерно и .т.к. я являюсь ее разработчиком, то решено было двинуть в 21 с явой наперевес.
регистрация и удаление датчиков в системе — это рилтайм процесс, который не требует каких-то действий со стороны persistance. нообработка данных — процесс неспешный и ресурсозатратный, потому для нормальной работы будет использоваться ферма ПК, и данные соотв-но будут храниться в БД.
входные данные от датчиков — это (с тточки зрения явы) набор 3rd party классов, поля которых( не все, но важные для обработки) я пытаюсь сохранять в БД, чтобы в будущем, по команде оператора, можно было их восстановить.
обработка данных проводится (в реализации на перл -многопроцессно) многопоточно. соотв-но я незнаю, как в java SE поведут себя hibernate persistence entitites в многопоточном режиме (я никогда этого не реализовывал еще и не дебажил. потому стараюсь подстелить себе сразу подстилку, чтобы не больно падать было)
вообщем-то потому и хочу этот пресловутый persistance layer использовать ровно настолько, насколько я его понимаю. т.е. положить\взять данные и более об этом persistence layer не вспоминать.



GT>>>Поставте аннотацию @Transactional на реализации сервиса с propagation=REQUIRED, а так же на реализации дао с propagation=MANDATORY. Так при вызове сервиса будет создана новая транзакция если ее не было, а на дао она же подхватится, или будет кинуто исключение если транзакции нет (чтобы нельзя было вызывать дао не из веб сервисов). На юнит тесте вообще не уверн нужна ли она.

A>>у меня нет веб-сервисов. вообще. спринг это еще и java SE все-таки.
A>> транзакции как раз создаются нормально, я же хочу получать not-managed-by-hibernate-entity на выходе сервиса. покурил еще документацию, похоже что это невозможно, если не делать deep copy объектов явно.
A>>для моих целей это не критично, потому оставляю как есть.

GT>А я и не говорил про веб сервиса.

GT>

GT>@Service
GT>public class PArentServiceImpl {
GT>

GT>Это обычный сервис. Транзакция есть только на момент вызова к примеру sf.getCurrentSession().get(Parent.class,id); о после возвращения результата ее уже не будет. А должна обрамлять весь вызов к сервису, т.к. если внутри сервиса, посреди бизнес операции вылетит эксепшен, а вы до этого поменяли данные, то первоначальные изменения будут сохранены — что не есть правильно. + если после возврата сущности надо будет подгрузить ленивых чайлдов, то без активной транзакции это не удастся.

A>>на юнит-тестах транзакции нужны, просто у каждого теста будет сделан rollback по его окончании ( это дефолтное поведение тестов для работы с орм) т..е все будет ок.

A>>все-равно спасибо за ответы )

GT>Кстати, дурной тон писать трансляцию в статическом методе.
GT>

GT>public static ParentData createData(Parent parent,IData data) {
GT>        setParent(parent).
GT>        ...
GT>        //копируем данные из data в свои поля
GT>     }
GT>

GT>Используйте для этого транслятор (некоторые называют ассемблер), — объект который конвертирует IData в ParentData и если надо — наоборот.
спасибо за совет, а есть ли смысл большойй (кроме красоты кода, которыф кроме меня никто не увидит)?
следование стандартным подходам хорошо, када есть время, а когда надо "вчера" о таких "мелочах" вспоминается в лучшем случае, после Nого рефакторинга
у меня, к сожалению, подход именно такой, что надо чтобы тест отрабатывал. а как там это все реализовано — не суть. дешевле железок наставить будет если что( не судите строго — я тоже человек и по 25часов в сутки не могу код писать)