I'm starting a new project using JPA 2 + Hibernate 4.2.6 for data access.
I have two tables in my DB representing two different kinds of Answer, so I have answer_type_a and answer_type_b tables.
The are identical except for one field.
Now I'm creating my model classes and I'd like to inherit my AnswerA and AnswerB entities from a commom super-class or interface Answer.
I read some docs about entity inheritance:
http://docs.oracle.com/javaee/6/tutorial/doc/bnbqn.html
http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/inheritance.html#inheritance-tablepersubclass
but I have not a clear view on how to structure my DB and my entity classes to achieve this. Can you help me?
You need table Answer - that is super for particular others, where you should place all common columns for answer_type_a and answer_type_b. Assume Answer.a_id is primary key, then answer_type_a.a_id answer_type_b.a_id are simultaneously PRIMARY KEY and FOREIGN KEY.
Of course don't forget to place distinguished columns to answer_type_a and answer_type_b
+---------+
| Answer |
+---------+ ----------------------->--+--------------+
| a_id +------) | answer_type_b|
---->-+--------------+ +--------------+
... | answer_type_a| | a_id |
+--------------+ ...
| a_id |
....
You need to create one class named Answer with the common fields and you will annotate it with #MappedSuperclass. Additionally, you will have 2 entity classes, named AnswerA and AnswerB which will only hold the "extra" fields.
If you have 2 tables, then you need to use the TABLE_PER_CLASS inheritance type. So add #Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) to the Answer class, and probably a #Table annotation to AnswerA and AnswerB.
But if I were you, I would use one table for all answers, with all the needed columns + one discriminator column so you can distinguish if a row is answer type a or type b.
Well, as I understand your question is about mapping:
You need a java class Answer which is actually your super class. As there is no corresponding DB table for that, it must be annotated with #MappedSuperclass
#MappedSuperclass
public class Answer {
//fields&properties
}
And now the two classes come, which are entities, as they are persisted in DB tables:
#Entity
#Table("answer_type_a")
public class AnswerA extends Answer {
//here you add the field that is not common with AnswerB
}
#Entity
#Table("answer_type_b")
public class AnswerB extends Answer {
//here you add the field that is not common with AnswerA
}
PS: IMHO you don't need any inheritance annotations, as the mapped super class is not an entity.
I recently was in a similar situation like you. The best solution found was using an abstract class as a super type, and extending that class to the concrete types (which will represent your entity).
So for your situation you would model something like this.
#MappedSuperClass
public abstract class Answer{
#Id
#GeneratedValue(strategy=GenerationType.IDENTITY)
public Integer id;
#Column
String commonFieldOne;
#Column
String commonFieldTwo;
#Column
String commonFieldThree;
...
}
Note that I used the #MappedSuperClass annotation. This tells JPA that this is a super class that will not be instantiated and should not have a database table associated with it.
Also note that the Id which will serve as the primary key for both child tables is defined in this class
Now for you concrete classes (which will be mapped to tables in you database), you would use the #Entity annotation.
#Entity
#Table("answer_type_a")
public class AnswerA extends Answer{
//All common fields from Answer table will be included in the DB tables as columns automatically
#Column
String uniqueFieldOne;
....
}
You can do the same for #Table("answer_type_b")
Hope this helps!
Just create one table in your database e.g answer which contains both fields. You must have three classes Class 1 : Answer, Class 2: Answer_Type_A extends Answer, Class 3: Answer_Type_B extends Answer. There will be an hbm file for Answer (superclass) and two hbm for each Answer_Type_A and Answer_Type_B. In sybclass hbm files include:
<hibernate-mapping> <subclass name="com.test.Answer_Type_A"
extends="com.test.Answer">
<property name="fieldA" />
</subclass>
</hibernate-mapping>
Related
I have a set of Java classes with the following UML diagram:
public class Invoice {
#Id
private long id;
...
}
public class InvoiceDetail {
#Id
private long id;
...
private String productName;
private int quantity;
private double price;
}
My purpose is using JPA annotations to establish the different relationships between them. There is a composition relationship between Invoice and InvoiceDetail, which is resolved using #Embedded and #Embeddable annotations for Invoice and InvoiceDetail respectively. However, a problem appears by establishing the relationships between InvoiceDetail, Class3 and Class4. In these relationships InvoiceDetail must be annotated as #Entity. However, when a class is annotated at the same time as #Entity and #Embeddable, the corresponding server will throw a runtime error during the deployment.
Basing on the information of this website, I have written the following possible solution:
#Entity
public class Invoice {
#Id
private long id;
...
#ElementCollection
#CollectionTable(name="INVOICEDETAIL", joinColumns=#JoinColumn(name="INVOICE_ID"))
private List<InvoiceDetail> invoiceDetails;
...
}
Would be this right in order to resolve my problem?
Thanks in advance.
Although without knowing what the classes really are it is hard to tell, I suppose that you have a design problem. The composition between Class1 and Class2 says that any Class2 instance only exists within the lifecycle of a corresponding Class1 instance. But on the other hand you have Class3 instances and Class4 instances which can / must have a relationship to a Class2 instance.
What I'm trying to say is that from my point of view the relationship between Class1 and Class2 should be a simple association and not a composition. Following this path Class2 would be an Entity in JPA and then you should have your problem solved.
I usually use #Embeddable for classes whose instances never exist by themselfes and #Entity for any class whose instances can exist without other instances. An address for example could be implemented either way but not on the same system. Address would be #Embeddable if I don't want to link addresses but it had to be #Entity if I want to make sure the same address isn't saved in more than one row.
[edit: added after classes 1 and 2 were renamed to Invoice and InvoiceDetails]
Having a composition between Invoice and InvoiceDetails makes perfect sense. But I still think you should avoid the need of double personality for InvoiceDetails. I can think of two solutions (both refactorings):
If you prefer having InvoiceDetails as #Embeddable you could change the associations of Class3 and Class4 to Invoice instead of InvoiceDetails. InvoiceDetails would still be traversable via the Invoice object.
If you prefer keeping the associations as is you could declare InvoiceDetails to be an entity. You could still achieve your composition with a cascading delete (see javax.persistence.CascadeType). As it seems that InvoiceDetails already has it's own table, this probably is the better option.
I checked my JPA applications and haven't found any occurence of the same class being #Entity and #Embeddable. Honestly, I doubt if this is possible at all because the official javadoc of #Embeddable says:
Specifies a class whose instances are stored as an intrinsic part of an owning entity and share the identity of the entity.
As #Entity has it's own identity, you would try to declare the same object having two identities - and this can't work.
[/edit]
[edit2: adding code for solution proposal #2]
This code should work with some assumptions (see below). This is the implementation of bi-directional navigation for a 1:n-relationship.
#Entity
public class Invoice {
#Id
private long id;
#OneToMany(mappedBy="invoice", cascade = CascadeType.ALL)
private List<InvoiceDetail> details;
}
#Entity
public class InvoiceDetails {
#Id
private long id;
#ManyToOne
#JoinColumn(name="invoice_id")
private Invoice invoice;
}
Assumptions: Tables are named like the entities, the foreign key column for invoice_details table is named "invoice_id" and both tables have a primary key column named "id". Note that the mappedBy-value "invoice" refers to the entity field while the name-value "invoice_id" refers to the database table.
Be cautious when deleting an Invoice object whose InvoiceDetails still are referenced by your Class3 or Class4 instances - you have to release these references first.
For information about JPA refer to these resources:
The Java EE 7 Tutorial: Persistence
Wikibooks: Java Persistence
Javadoc of Package javax.persistence
[/edit]
[This scenario is for illustration]
I have certain products, and each product can have comments. Comments are of two types, general comments(GC) and product comments (PC).
Sample Tables
PRODUCT
ID NAME
1 APPLE
--
PRODUCT_COMMENTS
COMMENT_ID | COMMENT | COMMENT_TYPE
1 | IPHONE IS GOOD | PC
2 | IPAD LOOKS GOOD |GC
3 | GENERAL COMMENT| GC
4 | PRODUCT COMMENT |PC
Assume that there is a foreign key from Product table to Product_comment table.
And I have a couple of classes mapping to these tables.
Product class and ProductComment class
Product class has a one-to-may relationship with ProductComment class.
public class Product {
private Long id;
private String productName;
private List<ProductComments> productComments;
private List<ProductComments> generalComments;
.....
}
Now my problem is, there are two separate list of comments (differentiated by the comment_type).
When I say
Product p = (Product)session.load(Product.class, new Long(1));
Is it possible to fetch the generalComments and productComments properly ? In the above example
generalComments list should contain ['IPAD LOOKS GOOD','GENERAL COMMENT'] and the productComments list should contain ['IPHONE IS GOOD','PRODUCT COMMENT'].
What sort of mapping should be done to achieve the above thing ?
Edit :
We use Hibernate 3.0 and hbm mapping files(not annotations).
Use #Where annotation. You can give SQL condition to limit which ones will be chosen. In your example it goes roughly as follows:
#Where(clause="COMMENT_TYPE = 'PC'")
private List<ProductComments> productComments;
#Where(clause="COMMENT_TYPE = 'GC'")
private List<ProductComments> generalComments;
Be aware that this limit values loaded from database, but not the values written to these lists. You have still via program logic control which kind of comments are written to these lists.
In this case I would choose to use inheritance for the sake of readability and type safety.
That means, create Comment.class GeneralComment.class and ProductComment.class.
You can choose 2 ways for dealing with the hierarchy :
Actual inheritance. each class represents an equivalent table joined by PK.
Object inheritance. discriminate the Comment.class values into the two other entities using a discriminator column :
on the Comment.class :
<discriminator column="discriminator_column" type="discriminator_type" force="true|false" insert="true|false" formula="arbitrary sql expression" />
on each subclass :
<subclass name="ClassName" discriminator-value="discriminator_value" proxy="ProxyInterface" lazy="true|false" dynamic-update="true|false" dynamic-insert="true|false" entity-name="EntityName" node="element-name" extends="SuperclassName"> <property .... /> ..... </subclass>
Now your code can look like :
public class Product {
private Long id;
private String productName;
private List<ProductComments> productComments;
private List<GeneralComments> generalComments;
.....
}
I need to create a relation in Hibernate, linking three tables: Survey, User and Group.
The Survey can be visible to a User or to a Group, and a Group is form of several Users.
My idea was to create a superclass for User and Group, and create a ManyToMany relationship between that superclass and Survey.
My problem is that Group, is not map to a table, but to a view, so I can't split the fields of Group among several tables -which would happen if I created a common superclass-.
I thought about creating a common interface, but mapping to them is not allowed.
I will probably end up going for a two relations solution (Survey-User and Survey-Group), but I don't like too much that approach.
I thought as well about creating a table that would look like:
Survey Id | ElementId | Type
ElementId would be the Group or UserId, and the type... the type of it.
Does anyone know how to achieve it using hibernate annotations? Any other ideas?
Thanks a lot
I posted a very similar answer yesterday. To summarize, you can't use a mapped superclass because a mapped superclass is not an entity and can't be part of an association (which is what you want) but you can use an abstract Entity with a TABLE_PER_CLASS inheritance strategy to obtain a similar result.
Something like this (not tested):
#Entity
#Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class AbstractEntity {
#Id #GeneratedValue(strategy = GenerationType.TABLE)
private Long id;
#ManyToMany(mappedBy="entities")
private Set<Survey> surveys = new HashSet<Survey>();
...
}
#Entity
public class User extends AbstractEntity {
...
}
#Entity
public class Group extends AbstractEntity {
...
}
#Entity
public class Survey {
#Id #GeneratedValue
private Long id;
#ManyToMany
private Set<AbstractEntity> entities = new HashSet<AbstractEntity>();
...
}
References
Annotations, inheritance and interfaces
using MappedSuperclass in relation one to many
Polymorphic association to a MappedSuperclass throws exception
You can use the table per concrete class inheritance strategy, hibernate will replicate all properties for each subclass, this will work with a view.
I would also suggest the composite pattern for users/groups (which is close to your first option).
http://en.wikipedia.org/wiki/Composite_pattern
This is possible. Such an 'inherited properties' approach can be achieved by defining the superclass as a MappedSuperclass.
EDIT:
There is also some alternatives listed in section 2.2.4 in the hibernate annotations reference doc, section 2.2.4.4 covers MappedSuperclass.
I have a Person entity mapped by Hibernate to a database table in a database catalog "Active". After a period of time, records in this database table in the "Active" catalog are archived/moved to an exact copy of the table in a database Catalog "History". I have the need to retrieve from both the Active and History Catalogs. Is there a better way to model this with Hibernate annotations than making an abstract class that 2 classes extend from.
This is what I have now.
#MappedSuperclass
public abstract class Person {
#Id
private Integer id;
private String name;
}
#Entity
#Table(name="Person", catalog="Active")
public class PersonActive extends Person {
}
#Entity
#Table(name="Person", catalog="History")
public class PersonHistory extends Person {
}
To my knowledge, that would be the right way to do it with annotations (you kinda have two tables so you need two entities). Then run a polymorphic query on the Person entity. I find this pretty clean by the way.
PS: Can you add a pointer on how to do this with mapping files, I'm really curious.
My thought would be to write a query to select both tables from db A and B. then create a query with hibernate and map it to your class.
example:
#Entity
#NamedNativeQuery(
name="GetAllPerson",
query="select * from A.Person inner join B.Person on A.Person.Id = B.Person.Id"
)
public class Person {
...
}
Not sure if it could work, your question made me also curious about the best way to do it :). I'll test it tonight after work and see if its any good.
I think there is a subproject of hibernate named shards. It is designed to work with multiple relational databases. If you want to use it, you may need big changes in your code.
I have an object with a field that can be a number of object types. This object is encoded in a single table with a discriminator column for the field's subtypes. Each of these subtypes have their fields mapped to a column in the parent objects table. I cannot seem to model this in hibernate. The code bellow will return null for getSubfield() regardless of what subtype data is in the table.
Schema
id type whosit whatsit
+----+------+--------+---------+
| 1 | "A" | "test" | null |
| 2 | "B" | null | "test" |
+----+------+--------+---------+
Domain Objects
#Entity
public class Parent {
protected #Id #GeneratedValue int id;
protected Subfield subfield;
public Subfield getSubfield() {return subfield;}
}
#Embeddable
#Inheritance(strategy=InheritanceType.SINGLE_TABLE)
#DiscriminatorColumn(name="type", discriminatorType=DiscriminatorType.STRING)
public abstract class Subfield {}
#DiscriminatorValue("A")
public class TypeA extends Subfield {
public String whosit;
}
#DiscriminatorValue("B")
public class TypeB extends Subfield {
public String whatsit;
}
"SELECT p FROM parent p"
{id=1,subfield=null}
{id=2,subfield=null}
Is it possible to accomplish what I want with this object model, or do I need to get a bit more creative (this is a legacy database, changing the schema is not preferred)
As pointed by the asker, hibernate does not support inheritance of embeddable classes (https://hibernate.atlassian.net/browse/HHH-1910).
According to the Eclipse wiki, the JPA does not specify this behavior, but EclipseLink does support it (http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Entities/Embeddable#Inheritance).
My suggestion is to smash the class hierachy entirely inside Subfield. Horrible, but should work until this is solved.
Ok you can't easily change the schema, but how about adding a couple of views?
I know this is old.
One way around this is as specified above. Create a view. You say you don't want to change the schema. Then don't. You can create a new schema which maps the old schema and does what you want. (Possibly depending on database)