|
|
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Добрый вечер! Посоветуйте пожалуйста: есть сущность hibernate. Есть GUI JavaFX, меняющие ее поля. Все это внутри Spring. Как оптимальным образом отловить факт того, что сущность "изменилась"? Мне не нужно знать что именно и каким образом - просто то что она в принципе была изменена. Сам hibernate такие сущности, если я верно понимаю, считает dirty, но какого-то "элементарного" (а-ля isDirty()) метода я не увидел. Видятся примерно такие пути: 1. Ставить флаг (либо в сущности на сеттерах либо в ГУИ на полях при изменении). Решение рабочее НО мне не нравится что если поставить "новое" значение а потом обратно "старое" флаг останется в положении "сущность была изменена". 2. Делать копию сущности и сравнивать все поля - не нравится потому что это ресурсы и время. 3. Делать "наблюдатель", но для такой "фигни" мне кажется это как из рушки по воробьям... 4. AOP тут не срабатывает (попробовал), потому что хибер делает прокси видимо. Словом мой "победитель" все же наверное флаг, но может есть что более оптимальное о чем я и не подозреваю? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2016, 23:48 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGab, hashCode ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2016, 00:42 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
а может аспект вешать не на саму сущность? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2016, 00:53 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
rdmRuslanGab, hashCode Да попробую. Спасибо. По идее то что мне нужно. Жалко только придется до понедельника ждать natanabrahamjrа может аспект вешать не на саму сущность? :) А на кого? Если на GUI так там нет "универсального сеттера" поля меняются и "вбиванием" текста и, к примеру, выбором чего-то в чекбоксе, и через DatePicker. На сущность было бы эдементарно - все что внутри такого-то пакета и все методы начинающиеся с SET. Увы так не прокатило:( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2016, 01:04 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabЕсли на GUI так там нет "универсального сеттера" Он причём? MVVM паттерн у JavaFX, вот в последнем слое перед ГУИ и делайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2016, 10:03 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Petro123, Нет я от MVVP отказался если честно - перед этим проект был где все было именно с MVVM и все ок, а тут просто "двухслойное" небольшое приложение без сервера и не захотел я это городить. Таки вот поимев опыт MVVM считаю все же что для таких "небольших" проектов оно того не стоит, хотя может я не прав конечно... Тут всего 8 или 9 полей заполняются включая боксы и datepickerы, так что меняю поля сущности просто посредством слушателей этой формы. С MVVM этот момент конечно в лет бы решился, но тут пожалуй и хэша хватит - при отображении сущности всего-то достаточно в локальную переменную сохранить ее копию а дальше когда надо сравнить хэш имеющейся сущности с этой самой копией и всех делов - очень мне понравилось решение. Как всегда на поверхности все лежит не надо мудрить... Но спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 10:30 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGab, Может и оверхед в вашем проекте. Про хэш этот метод точно работает? Код покажите тогда, раз вопрос решён. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 13:34 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabКак оптимальным образом отловить факт того, что сущность "изменилась"? DefaultSaveOrUpdateEventListener либо заюзать Service/DAO/Repository и fire'ить вручную ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 15:13 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Petro123, Попробую завтра нормально ли будет с хэшем. А отчего хэшу не работать? Переопределю его во всех энтитях (если уже это не сделано - не помню), коих не много, чтобы и с "дочерними" нормально проходило и по идее все. Ну я надеюсь по крайней мере. Код покажу проблемы нет. Завтра будет возможность только. Usman, Насчет DefaultSaveOrUpdateEventListener насколько я понимаю "listener used by Hibernate for handling save-update events" означает, что он сработает перед апдэйтом/сэйвом. Это не совсем то что я ищу. Мне-то просто нужно в требуемый мне момент знать изменен/нет и все. "заюзать ... и fire'ить вручную" - это собственно то что я имел ввиду под "флагом" - ставить его на "да" при изменении полей. Да так будет работать я просто и хотел знать может есть что проще уже готовое. К тому же идей со "флагом" имеет небольшой баг если поменять поле и позже поменять "обратно" - флаг останется в true хотя по сути ничего не менялось. Вот хэш ранее "посоветованный" мне кажется тем что надо как раз в моем случае. Всем спасибо еще раз! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 16:32 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabА отчего хэшу не работать? Переопределю его во всех энтитях просто странный ты. Вместо того чтобы в каждой сущности сделать флаг об изменении, т.е. одно доп.поле. Ты будешь переписывать во всех сущностях проверку всех полей. Пока, по ТЗ получается что оверхед у тебя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 19:12 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabДобрый вечер! Посоветуйте пожалуйста: есть сущность hibernate. Есть GUI JavaFX, меняющие ее поля. Все это внутри Spring. Как оптимальным образом отловить факт того, что сущность "изменилась"? Мне не нужно знать что именно и каким образом - просто то что она в принципе была изменена. Сам hibernate такие сущности, если я верно понимаю, считает dirty, но какого-то "элементарного" (а-ля isDirty()) метода я не увидел. Видятся примерно такие пути: 1. Ставить флаг (либо в сущности на сеттерах либо в ГУИ на полях при изменении). Решение рабочее НО мне не нравится что если поставить "новое" значение а потом обратно "старое" флаг останется в положении "сущность была изменена". 2. Делать копию сущности и сравнивать все поля - не нравится потому что это ресурсы и время. 3. Делать "наблюдатель", но для такой "фигни" мне кажется это как из рушки по воробьям... 4. AOP тут не срабатывает (попробовал), потому что хибер делает прокси видимо. Словом мой "победитель" все же наверное флаг, но может есть что более оптимальное о чем я и не подозреваю? Спасибо. не спец в Java. но врядли это нормальный подход: "есть сущность hibernate. Есть GUI JavaFX, меняющие ее поля". на ГУИ должны быть другие типы, у которых есть возможность 2-направленного биндинга к контролам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 19:17 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabК тому же идей со "флагом" имеет небольшой баг если поменять поле и позже поменять "обратно" - флаг останется в true хотя по сути ничего не менялось. Вот хэш ранее "посоветованный" мне кажется тем что надо как раз в моем случае. ну, во-первых, это нормально когда в ворд я добавил символ, потом стёр, а звёздочка изменения документа так и осталась. Хотя что мы говорим. Для чего сабж ты так и не сказал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 19:17 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Petro123Для чего сабж ты так и не сказал. Да я не думал что это сильно важно До смешного просто все: если выбирается сущность (из таблицы tableview) снизу "выезжает" панель с полями для ее редактирования. Там же ок (что очевидно) и cancel. Весь сыр бор чтобы по нажатию на cancel а также на любую из прочих доступных опций в главном меню (оно сверху ну опять же не важно) глянуть была ли сущность изменена и если да сказать мол "Момент, ты же тут че-то менял. Точно хочешь уйти не сохранив?". Вот и усе... fsharp_fsharpна ГУИ должны быть другие типы, у которых есть возможность 2-направленного биндинга к контролам Я понимаю о чем вы говорили у меня на прошлом проекте так былою BindBidirectional прекрасно работает если вы делаете модель с XYZproperties, т.е. используете MVVM, от чего я отказался, ибо тут всего несколько полей редактируется решил что "слушателей" на них повесить проще. Есть конечно также вариант в модели и простые свойства и всякий StringProperty и прочие "замешать", но там проблемы с сереализацией да и вообще не очень мне такое решение. Словом у меня совсем обычная модель и простые листнеры, которые поля сущности меняют через сеттеры. Petro123Вместо того чтобы в каждой сущности сделать флаг об изменении, т.е. одно доп.поле. Ты будешь переписывать во всех сущностях проверку всех полей. Не совсем согласен. Флаг да одно поле, но его еще надо в каждый сеттер:) Конечно сложного ничего (тем более там сущностей всего ничего) и собственно это и был мой выбор если тут лучшего не посоветуют, но хэш как по мне так все же проще. Что там такого проблемного в "проверке всех полей"? Овверрайд метод ХэшКод и IDE сама сгенерит код строк на 7-10. И сделать это скажем раз 5. Искренне не вижу трудностей или проблем. Есть конечно теоретичские сомнения что при изменении дочерней сущности что-то будет "не так", но вообще говоря по идее все должно быть ок. А впоследствии этот подход еще и решит проблему сущности, которую изменили и изменили "назад" - если поменять "назад" хэш станет прежним. По идее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2016, 23:20 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabФлаг да одно поле, но его еще надо в каждый сеттер:) ешкин кот. - Далай один флаг на сессию а не на сущность. Зачем знать что именно изменилось? - Ты предлагаешь перед выводом копировать сущности? Это же тоже код? Потом добавим код проверки по хешу или equals. Потом учтём что ID не должен проверятся на равность объектов. Потом учтём что сессии короткие и ты копию сущности должен вывести из сессии хибера. - Как будем сравнивать сложный объект один ко многим - Персона с дочками-детьми. ... И это всё вместо одной галки SetModify и GetModify boolean? ... С точки зрения архитектуры, hashCode equals более системные вещи. А то что вы ищите - бизнес логика. Я бы не мешал одно с другим. Но это IMHO. Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 00:44 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 01:17 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 01:25 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
rdm Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. В вашем примере ресет надо будет вызывать из каждого сеттера? Тогда ведь это тот же "флаг" по сути, правда лишенный того что он будет выставлен при том что ищменения будут "возвращены". Вообще мне очень нравится решение. Если исходить из поста ниже что "@override hashCode" зло, то это решение вообще идеальное. Usman , интересная статья, но я так и не понял чем конкретно это плохо если честно. Тем что после сохранения сущности в базе код станет другой? Так меня только часть "до сохранения" интересует... Не знаю словом. Я видел переопределение этих методов в проекте, которым руководил "опытный дядька" не то что я - все работало. Наверное и недостатки есть но для меня это пока не совсем очевидно... Ну что, по моему мнению и проверке "на скорую руку" хэш таки показал себя молодцом. Изменения полей в сущности и в дочерних сущностях отрабатывают как надо - в том числе сущность получает первоначальный хэш если эти изменения "откатить". Обещанный код привожу, но полотно на 2 км думаю будет перебор - тут для примера сущность с одной дочерней (не смотрите на обилие полей - редактируемы из них только половина) а также контроллер (частично) AnchorPane, в которой собственно представлены ГУИ для редактирования. Пока логики проверки по сути нет - только вывод в консоль при нажатии "cancel". Однако подбное сравнение будет позже и в "родительском" контроллере (он передает в этот контрллер объект в метод "setAnfrageItem"). Мне решение с хэшем применительно к моей задаче понравилось, но я парень неопытный если это чем-то совсем плохо с удовольствием пересмотрю. И еще раз всем спасибо! "Основная" сущность: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. Одна из дочерних Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. Контроллер (выдержки - очень уж он уже разросся да и сыро все это пока что): Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. Как-то коли кому интересно - тут наверное совсем все пока сыро вы уж сильно не пинайте:( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:14 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGabВ вашем примере ресет надо будет вызывать из каждого сеттера? Нет, один раз перед редактированием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:19 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Petro123ешкин кот. - Далай один флаг на сессию а не на сущность. Зачем знать что именно изменилось? Сорри ваш пост проглядел когда писал. Ээээ. Ну да. Это мне и надо. Простоите за тупизм, но КАК это делается? Я искренне не понимаю что значит "флаг на сессию" и как с этим работать... Вы ранее писали автор"Вместо того чтобы в каждой сущности сделать флаг об изменении, т.е. одно доп.поле.", что я себе представил обычным boolean, который я меняю на true в каждом сеттере, но теперь я так понимаю что я вас не так понял. Дадите ссылку где глянуть? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:24 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
rdmRuslanGabВ вашем примере ресет надо будет вызывать из каждого сеттера? Нет, один раз перед редактированием. Нет у меня немного иная логика поэтому так в моем случае не получится. При редактировании поля в контрлллере редактируется (через сеттер) поле в сущности. Полей соответственно несколько - надо либо в каждое поле либо в каждый сеттер "залезть" чтобы флаг поставить выходит. Ну или я еще сплю и совсем не понимаю что мне добрые люди донести пытаются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:28 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGab, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:35 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
rdmRuslanGab, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. понял Спасибо!!! Замучил всех совсем даже неудобно из-за таких пустяков... Решение хорошее и "родственно" моему. Плюс моего (переопределение хэша): - не надо добавлять ничего в "листнеры" Плюс вашего: - не надо переопределять хэш и удобный доступ к состоянию сущности из любого места впоследствии. Пожалуй ваше решение лучше. Попробую с ним, правда сейчас завал на другом проекте наверное вечерком или завтра руки дойдут. Спасибо еще раз! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 10:43 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
RuslanGab, решений было 2: - хэшкод и переменная-галка в сессии Я_редактировал, вызываемая из любого листенера-события. Ты ведь всё равно их будешь писать и их у тебя 10-20 штук. В больших системах это делается на уровне DAL - доступ к данным. Но во-первых ты сам повырезал все слои и сказал что ты упрощаешь. Во вторых, тут ОРМ. И у него объект равен объекту только по ID или ключу в БД. Тут главное не смешать свой equals с тем что использует хибер. Объект у которого в поле одна буква другая (не ключевом) хибером рассматривается как оди и тот же. У тебя они разные. ... Так что сам смотри. Для галки в сессии будет 10-20 строк. Для хэша будет много больше + тестирование. Удачи! ЗЫ. Снимать флаг о редактировании после "поправил взад" не нужно. Это черезчур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 11:41 |
|
||
|
Как оптимально слушать изменения в сущности?
|
|||
|---|---|---|---|
|
#18+
Petro123, Спасибо! Буду пробовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2016, 11:46 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39303354&tid=2123752]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 201ms |
| total: | 363ms |

| 0 / 0 |
