Как изменить тип объекта в JPA?

Итак, я наконец нашел рабочее решение:

Откажитесь от EntityManager для обновления DTYPE. В основном это связано с тем, что Query.executeUpdate() должен выполняться внутри транзакции. Вы можете попробовать запустить его в существующей транзакции, но это, вероятно, связано с тем же контекстом сохраняемости объекта, который вы изменяете. Это означает, что после обновления DTYPE вы должны найти способ evict() сущности. Самый простой способ — вызвать entityManager.clear(), но это приводит к всевозможным побочным эффектам (читайте об этом в спецификации JPA). Лучшее решение — получить базового делегата (в моем случае Hibernate Session) и вызвать Session.evict(user). Это, вероятно, будет работать на простых доменных графах, но мои были очень сложными. Мне так и не удалось заставить @Cascade(CascadeType.EVICT) правильно работать с моими существующими аннотациями JPA, такими как @OneToOne(cascade = CascadeType.ALL). Я также попытался вручную передать моему графу домена Session и заставить каждую родительскую сущность вытеснить своих дочерних элементов. Это также не сработало по неизвестным причинам.

Я оказался в ситуации, когда сработает только entityManager.clear(), но я не мог смириться с побочными эффектами. Затем я попытался создать отдельную единицу персистентности специально для конверсий сущностей. Я подумал, что могу локализовать операцию clear() только для того ПК, который отвечает за конверсии. Я настроил новый ПК, новую соответствующую EntityManagerFactory, новый менеджер транзакций для него и вручную внедрил этот менеджер транзакций в репозиторий для ручной упаковки executeUpdate(). в транзакции, соответствующей соответствующему ПК. Здесь я должен сказать, что я недостаточно знаю о транзакциях, управляемых контейнером Spring/JPA, потому что это закончилось кошмаром, пытаясь получить локальную/ручную транзакцию для executeUpdate(), чтобы хорошо работать с транзакция, управляемая контейнером, извлекается из уровня службы.

В этот момент я выбросил все и создал этот класс:

@Transactional(propagation = Propagation.NOT_SUPPORTED)
public class JdbcUserConversionRepository implements UserConversionRepository {

@Resource
private UserService userService;

private JdbcTemplate jdbcTemplate;

@Override
@SuppressWarnings("unchecked")
public User convertUserType(final User user, final Class targetClass) {

        // Update the DTYPE
        jdbcTemplate.update("update user set user.DTYPE = ? where user.id = ?", new Object[] { targetClass.getSimpleName(), user.getId() });

        // Before we try to load our converted User back into the Persistence
        // Context, we need to remove them from the PC so the EntityManager
        // doesn't try to load the cached one in the PC. Keep in mind that all
        // of the child Entities of this User will remain in the PC. This would
        // normally cause a problem when the PC is flushed, throwing a detached
        // entity exception. In this specific case, we return a new User
        // reference which replaces the old one. This means if we just evict the
        // User, then remove all references to it, the PC will not be able to
        // drill down into the children and try to persist them.
        userService.evictUser(user);

        // Reload the converted User into the Persistence Context
        return userService.getUserById(user.getId());
    }

    public void setDataSource(final DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }
}

Есть две важные части этого метода, которые, я считаю, заставляют его работать:

1. Я пометил его с помощью @Transactional(propagation = Propagation.NOT_SUPPORTED), что должно приостановить транзакцию, управляемую контейнером, поступающую из сервисного уровня, и разрешить преобразование вне ПК.
2. Перед попыткой перезагрузить преобразованную сущность обратно на ПК я удаляю старую копию, хранящуюся в настоящее время на ПК, с помощью userService.evictUser(user);. Код для этого просто получает экземпляр Session и вызывает evict(user). См. комментарии в коде для получения более подробной информации, но в основном, если мы не сделаем этого, любые вызовы getUser попытаются вернуть кэшированную сущность, все еще находящуюся на ПК, за исключением того, что она выдаст ошибку о тип отличается.

Хотя мои первоначальные тесты прошли хорошо, это решение все еще может иметь некоторые проблемы. Я буду держать это в курсе, как только они будут обнаружены.

Вам действительно нужно представлять уровень подписки в типе User? Почему бы вам не добавить тип подписки в вашу систему?

Тогда отношение будет выражено следующим образом: Пользователь имеет одну Подписку. Его также можно смоделировать как отношение «один ко многим», если вы хотите сохранить историю подписок.

Затем, когда вы хотите изменить уровень подписки пользователя, вместо создания экземпляра нового пользователя вы должны создать новую подписку и назначить ее пользователю.

// When you user signs up
User.setSubscription(new FreeSubscription());

// When he upgrades to a paying account
User.setSubscription(new PayingSubscription());

Действительно ли TrialUser сильно отличается от PayingUser? Возможно нет. Вам лучше будет обслуживать агрегацию вместо наследования.

Данные подписки могут храниться в отдельной таблице (сопоставляться как сущность) или внутри таблицы пользователей (сопоставляться как компонент).

Проблема больше связана с Java, чем с чем-либо еще. Вы не можете изменить тип экземпляра во время выполнения (во время выполнения), поэтому спящий режим не предусматривает такие сценарии (в отличие, например, от рельсов).

Если вы хотите исключить пользователя из сеанса, вам придется исключить связанные сущности. У вас есть несколько вариантов:

• Сопоставьте сущность с помощью evict=cascade (см. Session#evict javadoc)
• Вручную удалить все связанные объекты (это может быть обременительно)
• Очистить сеанс, тем самым вытеснив все объекты (конечно, вы потеряете локальный кеш сеанса)

У меня была аналогичная проблема в Grails, и мое решение похоже на решение григория. Я копирую все поля экземпляра, включая связанные сущности, затем удаляю старую сущность и записываю новую. Если у вас не так много отношений, это может быть легко, но если ваша модель данных сложна, вам будет лучше использовать описанное вами собственное решение sql.

Вот источник, если интересно:

def convertToPacient = {
    withPerson(params.id) {person ->
      def pacient = new Pacient()
      pacient.properties = person.properties
      pacient.id = null
      pacient.processNumber = params.processNumber
      def ap = new Appointment(params)
      pacient.addToAppointments(ap);

      Person.withTransaction {tx ->
        if (pacient.validate() && !pacient.hasErrors()) {

          //to avoid the "Found two representations of same collection" error
          //pacient.attachments = new HashSet(person.attachments);
          //pacient.memberships = new HashSet(person.memberships);
          def groups = person?.memberships?.collect {m -> Group.get(m.group.id)}
          def attachs = []
          person.attachments.each {a ->
            def att = new Attachment()
            att.properties = a.properties
            attachs << att
          }

          //need an in in order to add the person to a group
          person.delete(flush: true)
          pacient.save(flush: true)
          groups.each {g -> pacient.addToGroup(g)};
          attachs.each {a -> pacient.addToAttachments(a)}
          //pacient.attachments.each {att -> att.id = null; att.version = null; att.person = pacient};

          if (!pacient.save()) {
            tx.setRollbackOnly()
            return
          }
        }
      }

Проблема больше связана с Java, чем с чем-либо еще. Вы не можете изменить тип экземпляра во время выполнения (во время выполнения), поэтому спящий режим не предусматривает такие сценарии (в отличие, например, от рельсов).

Я столкнулся с этим сообщением, потому что у меня (или думал, что у меня есть) аналогичная проблема. Я пришел к выводу, что проблема не в механике смены типов в технологии, а в том, что эволюция типов в целом вовсе не проста и не проста. Проблема в том, что типы довольно часто имеют различные атрибуты. Если вы не сопоставляете разные типы только для различий в поведении, неясно, что делать с дополнительной информацией. По этой причине имеет смысл мигрировать типы на основе построения новых объектов.

Проблема не связана с Java. это связано с теорией типов в целом и, более конкретно, с объектно-реляционным отображением здесь. Если ваш язык поддерживает ввод текста, я хотел бы услышать, как вы можете автоматически изменять тип объекта во время выполнения и волшебным образом делать что-то разумное с оставшейся информацией. Пока мы распространяем FUD: остерегайтесь того, от кого вы советуетесь: Rails — это фреймворк, Ruby — это язык.

Когда вы говорите о преобразовании, вы, вероятно, искажаете проблему. На мой взгляд, вы действительно пытаетесь создать экземпляр одного класса на основе экземпляра другого класса, например:

public PayingUser(TrialUser theUser) {
...
}

Затем вы можете удалить старого пробного пользователя и сохранить нового платного пользователя.