Мне нужно сохранять историю изменений Entities в таблицу истории.
Пытаюсь сделать это через EntityListener - @PreUpdate, вроде по логике должно быть именно так.
Но, дело в том что из нутри Entity нету инджекшен @PersistanceContext.
Какое правильное решение для такого дела?

Для ведения истории обычно entity имеет поле для версии и из БД их просто не удаляют.

Я уже думал об этом, но нужно именно копировать в другую таблицу.

Добавлено через 2 минуты и 2 секунды
powerOn, 
Кстати, а если сделать так как ты сказал. То каким образом задавать EntityManager-у условие подбора правильного Entity?

Добавлено через 3 минуты и 1 секунду

И ещё: как бы это ни было, мне нужен @PersistanceContext.

Через запрос в котором так же будет указана версия объекта. Вообще тут нужно конкретный use case рассмотреть. Возможно, какое-нибудь вообще другое решение подойдет... 


В Entity классе его автоматически не получить, поскольку они не управляются контейнером. Эти объекты ты создаешь сам, в отличии от EJB, которые для тебя создал и проинициализировал контейнер EJB. Вот контейнер создавая EJB позаботился о том, чтоб ссылка на EntityManager была поставленна корректно, а ты создавая свои entity нет. ;-) 
Получается что выход тут один (вернее два): 
1) самостоятельно передавать ссылку на EntityManager в слушателя сущностей. Замечу, что разметить аннотациями @PreUpdate и др. можно не только саму сущность, но и другой класс, подключив его в последствии к сущности как слушателя через аннотацию @EntityListeners.
2) Сделать так что бы слушатель сущностей сам находил подходящего EntityManager-а. Например через JNDI lookup.

А это интересно... Может ли быть EJB слушателем?

Как простой класс может, но его создавать будет не контейнер EJB, а значит и инжектировать EntityManager не получится... Оно и понятно, ведь в JavaSE приложениях тоже можно использовать JPA и создавать @EntityListeners, а там то не никакого EJB контейнера, все на плечи JPA имплементации положено...

Господа, может я и не по теме, но согласно пожеланиям автора темы такую задачу можно решить еще и таким простым способом:
повесить в базе триггер на апдейт основной таблицы и ложить в другую таблицу копию измененной записи.
А все остальное, соответственно, согласно логики приложения. Может триггеры и не помогут...

У меня такая  идея:
Сделать Message Driven Bean который всего лиш будет принимать обьект Entity, причём не важно какой, и загонять его в базу.
При этом, сам Entity, которому нужна история, будет создавать копию исторического Entity для самого себя, и отправлять в Bean.

Добавлено через 1 минуту и 13 секунд

Есть что то такое?

Всё таки всё перекрутил и решол делать как ты предложил.
Получилось следующее:



но сразу появились пару вопросов:
1. В моём случае я не могу пользоваться точьной датой. Так что получается что вот это

не сработает.
2. Каким образом мапается этот Entity к Customer::type?

На первый вопрос я вроде как могу ответить сказав что так как персистер пользуется методом equals(Object obj)  что бы найти подходящий ключ, то это метод можно просто изменить так как нам нужно (дата должна быть не равна а между effective и expiration) и спокойно пользоваться em.find(CustomerType.class, new CustomerTypeId(id, new Date()));. Исправь если я не прав.

А вот на тему второго у меня даже догадок никаких.

Что-то я плохо вопросы понял... Что сделать-то хочешь? Составной ключ (из числа и даты) и поиск по нему?



Если Customer::type это как раз и есть составной ключ, то обычно его сущностью мапят с помощью @IdClass аннотации. 

powerOn, 

Дело не в этом.
Когда составной ключь это 2 цифры которые должны совпадать, то всё понятно.
В моём случае:
id - должен совпадать, а дата должна быть >= effectiveDate.

Это сообщение отредактировал(а) ShurikA - 7.1.2009, 21:19

Что мешает на JPAQuery запрос написать?

Абсолютно ничего, тогда когда я хочу прото найти определённый обьект.

А теперь преставь себе что есть Customer у которого есть relationship (соответственно ManyToOne со стороны Customer, так как нужен только последний effective CustomerType)

В таком случае Customer должен выглядеть примерно вот так:


Как ты понимаешь, если делать mapping только по одной колонке, то вряд ли мне принесётся effectiveCustomerType.

Есть ли в TopLink что то вроде @Where, как в Hibernate?

Нет, Topllink реализует спецификацию JPA. Все что в спеке есть, все реализовано в Toplink (кроме Table per Concrete Class, ЕМНИП).

Хотелось бы для начала понять отношение сущностей в твоей доменной модели... что нужно в результате получить... может тогда какое решение и придумается...