Est-il possible de * transformer * le type d'une entité Hibernate/JPA polymorphe?

Question

MISE À JOUR: après publication, j'ai découvert qu'il s'agit d'un doublon de this older question.

---

J'ai une exigence d'affaires étrange: mon application prend en charge les utilisateurs ont commencé à se comme « invités », puis enregistrer plus tard pour devenir des utilisateurs « enregistrés ».

Les invités sont limités dans les fonctionnalités: ils ne sont pas autorisés à accéder à certaines fonctionnalités qui sont disponibles une fois enregistrés. Cependant, ils ont accès à un sous-ensemble de fonctionnalités et peuvent commencer à accumuler des données persistantes avant de s'enregistrer. Un grand nombre de ces fonctionnalités seraient modélisées en tant que méthodes sur une classe d'entités Utilisateur, et les données accumulées seraient naturellement associées via l'ID @ Guest de GuestUser.

Par conséquent, je contemple la modélisation de ce JPA/Hibernate comme un type polymorphes d'entité:

 
      User 
      ^
      | 
     +-------------+ 
     |    | 
    GuestUser RegisteredUser 

J'ai cartographié en utilisant une colonne discriminante booléenne; aucun problème:

@DiscriminatorColumn(name="guest", discriminatorType=DiscriminatorType.INTEGER) 

Cela fonctionne bien jusqu'à ce qu'un GuestUser décide de "registre" ...?!

Maintenant, je voudrais transformer mon GuestUser en RegisteredUser, en mettant

guestUser.guest = false; 

Le résultat de cette transformation serait logiquement pour purger l'objet GuestUser de l'existence, puis chercher un RegisteredUser équivalent avec le même Identifiant et champs partagés provenant des mappages utilisateur hérités.

Est-ce possible? Pourrais-je utiliser entityManager.refresh() pour obtenir le résultat souhaité? Puis-je créer une instance RegisteredUser et affecter manuellement son ID à la valeur du GuestUser existant? (Cette idée ID affectation semble problématique, car notre base de données existante nécessite GenerationType.AUTO.)

Answer 1

Avez-vous essayé de changer le drapeau invité, enregistrer les modifications, puis le chargement d'un nouvel objet à partir de la base de données avec le même User.ID?

Answer 2

Préférer la délégation à l'héritage. C'est mieux de toute façon mieux conçu et plus facile à cartographier d'une manière qui traite de ce changement proprement. Plutôt que de distinguer par sous-type, créez un rôle qui peut être réaffecté lorsque vous souhaitez modifier ce à quoi ils peuvent accéder.