Quand la JPA définir un @GeneratedValue @Id

J'ai un simple JPA entité qui utilise un générés long "ID" comme clé primaire:

@Entity
public class Player {
   private long id;

   protected Player() {
     //Do nothing; id defaults to 0L
   }


   @GeneratedValue
   @Id
   public long getId() {
      return id;
   }

   protected void setId(final long id) {
      this.id = id;
   }
   //Other code
}

À un certain moment dans le cycle de vie d'un objet de ce type, le PCA doit appeler setId() pour enregistrer l'IDENTIFIANT généré de la valeur. Ma question est, quand est-ce possible, et où est la documentation que les membres de cette. J'ai regardé à travers la Spécification JPA et ne peut pas trouver un énoncé clair.

La Spécification JPA dit (italiques ajoutés):

Une entité gérée instance est une instance avec une persistante identité qui est actuellement associée à un contexte de persistance.

Est que d'essayer de dire que l'objet doit être géré avoir son @Id importante?
La documentation pour EntityManager.persist() dit (emphase ajoutée), il fait "une instance géré et persistante", cela veut-il dire que le @Id est défini par cette méthode? Ou n'est-il pas jusqu'à ce que vous appelez EntityTransaction.commit()?

Lorsque le @Id est défini peut être différente pour différents JPA fournisseurs, et peut-être pour les différentes stratégies de génération. Mais ce qui est le plus sûr (portable, spécification conforme) hypothèse que vous pouvez faire sur le premier point dans le cycle de vie qu'elle a été définie?

  • Sonne comme quelque chose que vous pourrait s'établir assez facilement avec le débogage.
  • Je serais prêt à parier que si spec n'est pas explicitement dire lorsque le @code doit être généré que c'est à gauche pour les vendeurs de décider.
  • Débogage vais vous dire comment APP fonctionne en interne, et vous dire les bits sont dialecte spécifique.
  • Liées, mais pas en double, question: stackoverflow.com/questions/8169640/...
InformationsquelleAutor Raedwald | 2012-01-31
  1. 21

    appel .persist() ne sera pas automatiquement réglée à la valeur de l'id. Votre fournisseur JPA permettra de s'assurer qu'il est réglé avant que l'entité n'est finalement écrit db. Donc, vous êtes en droit de supposer que l'id sera attribuée lorsque la transaction est validée. Mais ce n'est pas le seul cas possible. Lorsque vous appelez .flush() le même qui va arriver.

    Thomas

    Mise à jour: attention à Geek commentaire, s'il vous plaît. -> Si GenerationType.L'identité est utilisé, l'id ne seront pas fixés par le fournisseur avant que l'entité n'est écrit db. Dans ce cas de génération d'identifiant qui se passe lors de l'insertion du processus sur le niveau de db. De toute façon, la JPA fournisseur veillera à ce que l'entité est mise à jour par la suite et l'id généré sera disponible dans le @Id annoté de la propriété.

    • Semble raisonnable. Donc, si vous appelez EntityManager.flush() pouvez-vous compter sur le @Generated @Id avoir été réglée? Je ne trouve pas d'indices dans la documentation.
    • Vous pouvez également jeter un oeil à ce post en veille prolongée forum: forum.hibernate.org/viewtopic.php?p=2384011#p2384011 Il semble dépendre choisi la stratégie du générateur
    • Selon l'EntityManager la documentation docs.oracle.com/javaee/6/api/javax/persistence/... de la chasse d'eau "Synchroniser le contexte de persistance de la base de données." Cela signifie que tous les collectifs instructions insert sera écrite dans la base de données pour synchroniser l'état. Pour faire votre fournisseur JPA a besoin de ces valeurs d'id. Donc, ils devraient être disponibles après l'appel de la chasse d'eau. Quelques stratégies qui pourraient les mettre plus tôt si.
    • Je pense que vous l'avez trouvé, mais je souhaite que les documents ont été plus clair. La partie correspondante de la norme est "3.2.4 de la Synchronisation de la Base de données: L'état de la persistance des entités est synchronisé avec la base de données lors de la validation des transactions. Cette synchronisation d'écriture à la base de données toutes les mises à jour les entités persistantes... [y compris] affectation d'une valeur à une propriété persistante ou d'un champ... La flush méthode peut être utilisée par l'application pour forcer la synchronisation".
    • vous pourriez suggérer quelques modifications ou des précisions à la JPA 2.1 Groupe d'Experts c'est à dire par le biais de leur liste de diffusion.
    • Vous avez écrit "Votre JPA fournisseur de s'assurer qu'il est réglé avant que l'entité n'est finalement écrit à db". Ce n'est pas tout à fait correct, parce que si vous utilisez strategy=GenerationType.IDENTITY, alors il est effectivement disponible uniquement après que l'entité est écrit à la db, pas avant qu'il est écrit dans la db.

    InformationsquelleAutor Thomas
  2. 11

    Autant que je sache, l'ID n'est garanti que pour être attribué que si le contexte de persistance est vidé. Il peut être attribué plus tôt, mais cela dépend de la stratégie de génération.

    InformationsquelleAutor JB Nizet
  3. 8

    Le livre de l'Entreprise Ejb 3.1 par Rubinger et Burke dit ce qui suit, à la page 143 (italiques ajoutés):

    Java Persistence peut également être configuré pour générer automatiquement une clé primaire lorsque le persist() méthode est appelée grâce à l'utilisation de la @GeneratedValue annotation sur le sommet du champ de clé primaire ou setter. Ainsi, dans l'exemple précédent, si nous avions automatique de génération de la clé activée, il peut afficher la clé générée après la persist() méthode terminé.

    La Spécification JPA dit (italiques ajoutés):

    Une entité gérée instance est une instance avec une persistante identité qui est actuellement associée à un contexte de persistance.

    Et aussi que EntityManager.persist() fait

    un exemple réussi et persistante

    Comme le @Id est cruciale pour la identité d'une entité, la seule façon pour EntityManager.persist() pour faire de l'objet géré est d'établir son identité par la génération de la @Id.

    Cependant

    Rubinger et Buke de déclaration claire est incompatible avec le comportement de mise en veille prolongée. Il semble donc que les personnes qui connaissent disgree sur ce que la spécification JPA entend.

    InformationsquelleAutor Raedwald
  4. 4

    Selon JSR 338: JavaTM Persistance 2.1 /3.5.3 la Sémantique du Cycle de Vie des Méthodes de Rappel pour les Entités,

    La PostPersist et PostRemove les méthodes de rappel sont appelées pour une entité à la suite de l'entité a été effectué de façon continue ou supprimé. Ces rappels seront également être appelée sur toutes les entités pour lesquelles ces opérations sont en cascade. Le PostPersist et PostRemove méthodes seront appelées après la base de données insérer et supprimer des opérations, respectivement. Ces opérations de base de données peut se produire directement après l'persistent, de fusionner ou de supprimer les opérations ont été invoquées ou ils peuvent se produire immédiatement après une opération de vidage a eu lieu (ce qui peut être à la fin de la transaction). Généré des valeurs de clé primaire sont disponibles dans la PostPersist méthode.

    Un possible (personnellement présumable) exception est GeneratorType.La TABLE lequel le conteneur (mai) récupère les valeurs à utiliser, et (mai) devant PrePersist. J'utilise toujours mon id dans PrePersist. Je ne suis pas sûr que cela comportements est spécifié ou peut ne pas fonctionner avec d'autres fournisseurs.

    important de modifier

    Pas tous les serveurs d'application id de jeu avant de PrePersist. Vous pouvez suivre JPA_SPEC.

    InformationsquelleAutor Jin Kwon