Это не сделает тебя счастливым.Я споткнулся из-за той же ошибки, собирался задать тот же вопрос на SO и увидел ваш.Эта вещь не работает, это серьезная ошибка.В документах, которые я нашел, «поскольку было бы утомительно явно вызывать save () для большого графа объектов, вызов save () автоматически каскадно связывается с аннотированным атрибутом cascade = CascadeType.ALL».но это просто не работает.
Я даже отлаживал SQL, что связано с вашими (и моими) ассоциациями в том, что они удаляются и повторно связываются с родителем, но они никогда не обновляютсяс новыми ценностями.Это что-то вроде этого:
//Here's it's updating a LaundryList where I've modified the address and one of the laundry items
//it first updates the simple values on the LaundryList:
update LaundryList set address=?, washDate=? where id=?
binding parameter [1] as [VARCHAR] - 123 bong st2
binding parameter [2] as [DATE] - Fri Mar 11 00:00:00 CET 2011
binding parameter [3] as [BIGINT] - 413
//then it deletes the older LaundryItem:
delete from LaundryList_LaundryItem where LaundryList_id=?
binding parameter [1] as [BIGINT] - 413
binding parameter [2] as [BIGINT] - 407
//here it's associating the laundry list to a different laundry item
insert into LaundryList_LaundryItem (LaundryList_id, laundryItems_id) values (?, ?)
binding parameter [1] as [BIGINT] - 413
binding parameter [2] as [BIGINT] - 408
//so where did you issue the SQL that adds the updated values to the associated LaundryItem??
Я видел ваш обходной путь, и я искренне ценю ваши усилия и тот факт, что вы постарались опубликовать его (так как это поможет людям, которые застряли с этим), но этопобеждает цель быстрого развития и ORM.Если я вынужден выполнять некоторые операции, которые обычно должны быть автоматическими (или даже не необходимыми, почему он удаляет старую ассоциацию и ассоциирует родительскую с новой, а не просто обновляет эту ассоциацию за один раз?), Тогда это не совсем так.«быстрое» или недействительное «объектно-реляционное отображение».
Насколько я понимаю, они взяли идеально работающую среду (JPA) и превратили ее во что-то бесполезное, изменив его поведение.В этом случае это относится к тому факту, что вызов JPA merge больше не делает то, что он должен, они говорят, что добавили свой собственный метод с именем "save", который помогает с этим (почему ???)и эта штука не работает так, как это описано в документации и примерах на их сайте (подробнее об этом в этом вопросе, который я отправил.
ОБНОВЛЕНИЕ:
Ну, вот и мой обходной путь:
Теперь я просто игнорирую, чтобы отправить идентификаторы обновленных ассоциаций в контроллер, таким образом, Play будет думать, что они новые сущности, которые будут добавлены в БД, ипри вызове merge (...) и save () для их родительской сущности все daya будут сохранены корректно, однако это вызывает у вас еще одну ошибку: с тех пор каждый раз, когда вы изменяете некоторые ассоциации и сохраняете родителя, эти ассоциации обрабатываются как новыесущности, которые будут созданы (они имеют id = null), и, таким образом, старые сохраняются от своих родителей при сохранении всего этого, что либо оставляет большую кучку осиротевших, бесполезныхсущностей в БД или заставляет вас писать еще более обходной код, чтобы очистить те осиротевшие связанные сущности в родительской сущности, которую вы собираетесь сохранить.
ОБНОВЛЕНИЕ 2:
На данный момент, я думаю, лучше подождать Play 2.0, который в настоящее время находится в бета-версии и будет запущен в ближайшее время.Это не слишком круто, так как, по словам мсье Борта (из памяти), «вы не сможете перенести свои проекты Play 1.x в Play 2 напрямую, но для переноса их будет достаточно легкого копирования и копирования».Скопируйте / вставьте свой код для победы!И подумать, сколько времени другие производители фреймворков тратят на обратную совместимость своей новой версии продукта!В любом случае, в своей статье , представляющей дорожную карту Play 2.0, они говорят, что они заменят Hibernate / JPA на какую-то другую инфраструктуру ORM, и в то же время признают, что взломали стандартную реализацию JPAсделано Hibernate для достижения ... ну, мы все видели, что это достигнуто.Вот цитата:
"Сегодня предпочтительным способом доступа приложения Java к приложению Play Java к базе данных SQL является библиотека Play Model, работающая на Hibernate. Но так как она раздражает в веб-среде без сохранения состояния, такой как Play, для управленияСостояния с состоянием, такие как те, которые определены в официальной спецификации JPA, мы предоставили особую разновидность JPA, позволяющую сохранять вещи как можно без состояний. Это заставило нас взломать Hibernate таким образом, который, вероятно, не будет устойчивым в долгосрочной перспективе.мы планируем перейти к существующей реализации JPA без сохранения состояния, которая называется EBean. "
Это может быть потенциальной хорошей новостью, поскольку новая ORM кажется более соответствующей их требованиям и с большей вероятностью избежит плохих вещей, которые они имеют сейчас.Я желаю им всем удачи.