J'ai quelques classes de modèle de domaine dans mon application Web qui ont une relation hiérarchique avec eux-mêmes. Un exemple d'une est la structure de catégorie hiérarchique utilisée pour classer les publications des utilisateurs.
Il existe une certaine logique relative à la nature hiérarchique de ces classes communes. Donc j'ai essayé de déplacer la logique en une superclasse annotée générique @mapsuperclass @MAPPAPPLACClass. P>
quelque chose comme: p> Les sous-classes, prolongent ensuite la fabrication hiérarchique se donner comme le générique TYPE N: P> Caused by: Exception [EclipseLink-7250] (Eclipse Persistence Services - 2.1.0.v20100614-r7608): org.eclipse.persistence.exceptions.ValidationException
Exception Description: [class net.timp.yaase.core.model.OnymBean] uses a non-entity [class net.timp.yaase.core.model.HierarchicalBaseEntity] as target entity in the relationship attribute [field parent].
at org.eclipse.persistence.exceptions.ValidationException.nonEntityTargetInRelationship(ValidationException.java:1341)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.RelationshipAccessor.getReferenceDescriptor(RelationshipAccessor.java:416)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.ObjectAccessor.processOneToOneForeignKeyRelationship(ObjectAccessor.java:609)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.ObjectAccessor.processOwningMappingKeys(ObjectAccessor.java:678)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.ManyToOneAccessor.process(ManyToOneAccessor.java:107)
3 Réponses :
Le problème est que lorsque vous utilisez des génériques comme types de champs pour les relations ECLIPSELINK ne peut pas savoir quel est le type de cible jusqu'au moment de l'exécution lorsque l'instance réelle est inspectée. Donc, la cartographie devrait être créée de manière dynamique au moment de l'exécution et celle-ci n'est pas prise en charge.
Vous pouvez continuer à utiliser la superclasse générique, mais cela nécessiterait de déplacer le champ sur les entités où ils seraient des types définis, puis des getters internes abstraits / setters pour les champs qui renvoient l'objet que les méthodes génériques appelleraient les méthodes génériques taper. Compliqué mais cela permettrait le générique mapperclass.
Bonjour Gordon, merci pour votre réponse. Je vais essayer votre suggestion de mettre les champs dans les sous-classes. Je peux voir comment cela fonctionnerait. J'ai actuellement une interface hiérarchique et une classe d'assistance statique avec la logique dans. Travaux, mais ce n'est pas aussi propre que je le souhaiterais. Je me demandais si @associationverride pourrait être utilisé pour redéfinir l'association.
Malheureusement, dans ce cas, le problème est avec le type d'attribut. @Associationverrides permet de modifier les informations de base de données mais n'a aucun attribut pour spécifier le type cible.
Bonjour Gordon, je ne trouve pas de solution plus propre que ce que vous avez suggéré de mettre en œuvre une superclasse pour la logique commune avec des getters abstraits. Donc, vous obtenez mon vote. D'AILLEURS. Savez-vous si cela est possible dans toute autre implémentation de la JPA ou fait-il partie de la spécification JPA?
Je ne sais pas si l'un des autres fournisseurs soutient cela, mais j'en doute. La spécification ne mentionne pas spécifiquement les types d'attribut génériques, mais les lecteurs sont avertis que les métadonnées de mappage ne sont pas portables.
Je pense que je suis en retard, mais les gens cherchent la réponse à ce problème (comme moi) devraient jeter un coup d'œil à ceci: https://bugs.eclipse.org/bugs/show_bug.cgi?id= 312132
L'autre fournisseur prenant en charge le type générique dans une relation persistante est .> OpenJPA . L'Assomption OpenJPA est que le champ de type générique est un type persistant et être annoté comme tel avec une annotation (OpenJPA-spécifique) @Type.
Cette annotation @Type agit comme un espace réservé pour le moteur de mappage OpenJPA et contient une cartographie où référence est une identité persistante de l'instance d'exécution. Il y a de nombreuses années, j'ai écrit un blog ; Je cite ici encore une fois de pas pour l'auto-promotion, mais j'espère que cela pourrait indiquer des sentiers pour vous permettre de prendre en charge un arbre générique sans avoir à repousser les informations de type concret sur une hiérarchie de type (et à la perte de l'essence du modèle de type générique ).
Cela ressemble d'une manière ou d'une autre similaire à forums.sun.com/thread. JSPA? Threadid = 5268944 (mais le problème correspondant est corrigé). Pourriez-vous essayer avec un autre fournisseur?