Comportement JPA étrange, champ initialisé est nul

Question

J'observe un comportement très étrange avec une classe d'entité et charge un objet de cette classe avec JPA (hibernate entitymanager 3.3.1.ga). La classe a un champ (imbriqué), qui est initialisé dans la déclaration. Le setter du champ implémente une vérification nulle (c'est-à-dire qu'il lève une exception lorsqu'une valeur nulle est définie).

... 
@Entity 
public class Participant extends BaseEntity implements Comparable<Participant> { 
    ... 
    @Embedded 
private AmsData amsData = new AmsData(); 

public void setAmsData(AmsData amsData) { 
    Checks.verifyArgNotNull(amsData, "amsdata"); 
    this.amsData = amsData; 
} 
    ... 
} 

Quand je reçois cet objet avec JPA, le champ est nul, s'il n'y a pas de données dans le DB pour les champs spécifiés dans l'objet incorporé.

... 
public class ParticipantJpaDao implements ParticipantDao { 
@PersistenceContext 
private EntityManager em; 

@Override 
public Participant getParticipant(Long id) { 
    return em.find(Participant.class, id); 
} 
    ... 
} 

Je débogué le processus avec un point d'observation sur le terrain (devrait arrêter lors de l'accès ou modifié le champ), et je vois une modification lorsque le champ est initialisé, mais quand je reçois le résultat de l'appel découverte , le champ est nul.

Quelqu'un peut-il expliquer, pourquoi c'est ainsi? Comment puis-je m'assurer que le champ n'est pas nul, même s'il n'y a pas de données pour les champs de l'objet incorporé dans la base de données (en plus de le définir manuellement après l'appel find).

Answer 1

La spécification JPA ne dit pas explicitement comment gérer un ensemble de colonnes représentant un objet intégrable qui sont toutes vides. Il peut signaler une référence NULL ou une instance d'objet avec tous les champs NULL. Hibernate choisit une référence nulle dans ce cas, bien que d'autres implémentations JPA puissent choisir cette dernière.

La raison pour laquelle votre setter n'est jamais appelé est parce que Hibernate accède à votre champ via la réflexion, en contournant le setter que vous avez implémenté. Il le fait parce que vous utilisez l'accès basé sur les champs plutôt que sur l'accès basé sur les propriétés.

La réponse du Tchad fournirait la fonctionnalité que vous recherchez, mais il y a une mise en garde (voir ci-dessous).

» ... L'état persistant d'une entité est accessible par la persistance exécution du fournisseur [1], soit par JavaBeans propriété de style accesseurs ou par les variables d'instance. Un type d'accès simple (champ ou une propriété accès) applique à une hiérarchie d'entités. Lorsque annotations sont utilisées, le placement des les annotations cartographiques soit sur les champs persistants ou persistants propriétés de la classe d'entité spécifie le type d'accès comme étant soit o feld [Spécification EJB3 persistance ] r propriété fondée sur l'accès respectivement ... »

donc en déplaçant les annotations vers le poseur, vous dites JPA que vous voulez utiliser l'accès basée sur la propriété au lieu de feld accès basé. Vous devez savoir, cependant, que l'accès basé sur un champ - tel que vous l'appliquez actuellement - est préféré à l'accès basé sur la propriété. Il existe plusieurs raisons pour lesquelles l'accès basé sur les propriétés est déconseillé, mais l'une d'entre elles est que vous êtes obligé d'ajouter des getters et des setters pour tous vos champs d'entité persistants, mais vous ne voulez pas que ces mêmes champs puissent être modifiés par des clients externes. En d'autres termes, l'utilisation de l'accès basé sur les propriétés de JPA vous oblige à affaiblir l'encapsulation de votre entité.

Answer 2

Eh bien, il est possible que votre objet soit construit deux fois en coulisses. Les implémentations JPA définissent généralement ces champs directement.

Je pense que vous devez mettre les annotations sur les Getters et les setters eux-mêmes si vous voulez qu'ils soient utilisés. Voir cette réponse:

Empty constructors and setters on JPA Entites

Answer 3

La réponse est (grâce à rcampell), si toutes les données d'un objet incorporé est nulle (dans le db), l'objet incorporé sera également nulle, bien que lors de son initialisation dans la déclaration. La seule solution semble être de régler l'objet manuellement.

@Override 
public Participant getParticipant(Long id) { 
    Participant participant = em.find(Participant.class, id); 
    if(participant != null && participant.getAmsData() == null) 
    { 
     participant.setAmsData(new AmsData()); 
    } 
    return participant; 
} 

se sent toujours étrange pour moi ...