Utilisation de JPA, pouvons-nous définir un énumé comme identifiant d'une entité?
J'ai essayé ce qui suit: Utilisation de OpenJPA, il se plaint: org.apache.openjpa.persistence.argumentException: la classe d'identification "Classe Aa.assetType" spécifiée par type "Class Aa.adKeys" n'a pas de constructeur de no-args public.
Donc, mes questions sont:
4 Réponses :
La spécification JPA ne dit pas que cela est possible:
2.1.4 Touches principales et identité d'entité
La clé principale (ou le champ ou la propriété d'une clé primaire composite) doit être l'un des types suivants: tout type primitif Java; tout type d'emballage primitif; java.lang.string; java.util.date; java.sql.date. En général, cependant, des types de chiffres approximatifs (par exemple, des types de points flottants) ne doivent jamais être utilisés dans les clés primaires. Entités dont les clés primaires utilisent des types autres que ceux-ci ne seront pas portables.
Si vous souhaitez vraiment avoir un nombre fixe de compilation d'enregistrements pour une entité donnée, vous pouvez utiliser une chaîne ou
int clé primaire et assignez-leAssetype.foo.name () ouAssetype.foo.Adinal ()et non portable ici signifie que certains fournisseurs de persistance peuvent supporter d'autres choses, mais cela pourrait ne pas fonctionner pour un autre fournisseur. Comme avec l'ENUM - si le fournisseur de persistance a un soutien particulier à celui-ci, cela n'essaie pas de l'instancier, mais le traite plutôt sur spécialement après avoir vérifié si
classe.isenum () , alors cela pourrait fonctionner. Mais il semble que votre fournisseur de persistance ne fait pas cela.
Cela ne dit pas que c'est possible mais ne dit pas que c'est impossible non plus. Cela dit simplement: «Entités dont les clés primaires utilisent des types autres que ceux-ci ne seront pas portables». En fait, cela ne dit pas aussi qu'une classe peut être utilisée comme clé primaire, mais elle est possible.
C'est une autre chose - une pièce d'identité intégrable. Voir ma mise à jour pour la partie portabilité.
Donc, je suppose que c'est une demande valide pour une amélioration, ne pensez-vous pas?
@Enumerated (EnumType.string) Cela signifie-t-il que la colonne est persistée en tant que valeur de chaîne? Oui, il est donc possible de l'utiliser comme une colonne @ID. Il existe des situations où il n'y a pas beaucoup d'entrées dans la table et vous devez faire référence à la chaîne. Numérique ID est le moyen le plus utilisé, mais d'autres types de données ne sont pas faux si utilisé correctement!
Ajout du lien à la source de la vérité serait utile.
Non, vous ne pouvez pas utiliser Enums comme ID comme ID car JPA ne permet pas de définir votre propre mappage pour les colonnes ID (ils doivent être IDS ne doit pas être la clé d'affaires (dans votre cas: le type). Utilisation de la clé Business comme une pièce d'identité est une erreur courante dans la DB Designs et doit être évitée car elle provoquera toutes sortes de problèmes plus tard.
Ajoutez une colonne d'identité indépendante pour résoudre le problème. int ou long ou quelque chose que JPA peut créer avec nouveau ).
Je travaille avec une vieille base de données. Ce n'est peut-être pas bon design mais c'est là. L'énum est juste un tas de valeur rigide.
Voulez-vous vraiment faire cela? Cette construction ne permet pas de modifier les touches de base de données Enum sans mettre à jour l'ENUM dans le code (échec sur la charge), ni l'inverse (défaillance des contraintes). Pourquoi ne créez-vous pas simplement une table d'assetype avec int pk et nom et que les adkeys ont une clé étrangère pour assettype.id comme pk?
Vous pouvez charger les asetypes à partir de la DB au démarrage si vous devez les énumérer dans votre application.
Je travaille avec une vieille base de données. Bien sûr, je peux le changer mais cela pourrait être problématique. L'énum est juste un tas de valeur rigide.
OpenJPA est le seul fournisseur JPA qui ne supporte pas cela. Voir Support Enum en tant que type de clé primaire
@Nathan: Alors, il doit s'agir d'un bug.