In my java I have a generic class (could be abstract or non-abstract either way, but does NOT map to a table in the database). It has one or more variables that are common to every class. Example:
public class GenericThing {
private Date createDate;
public Date getCreateDate() {
return createDate;
}
public void setCreateDate(Date dt) {
createDate = dt;
}
}
This is useful because literally every table in the database has the column CREATE_DATE.
In this case the right inheritance strategy to use in Hibernate is "table per concrete class". But, this is "bad", they say, because each table requires that identical column and if you change that column name (CREATE_DATE) you have to change every table's column name. Well, obviously this is true, but what is the alternative? Obviously I do want every table in the database to store the Create Date, but I don't want every object in the entire database to be in one table, so that precludes (as far as I know) all the other mapping strategies, right?
Actually for your usecase, nothing wrong in using Table per concrete class strategy
The problem you are trying to solve is not creating any redundancy at schema level(when tables are created). Even if we do the entity modelling in reverse mode, this is fine. In-fact, create_date is specific to each row for every table.
Table per concrete class is not recommended only when you are dealing normal inheritance for example User -> Customer -> Supplier where each extended class is a kind of parent class and the specific extra attributes added in the sub class need not be duplicated in the all the tables (Join Table strategy is recommended for such cases)
What's wrong with table pet subclass polymorphism? The parent table contains the commom columns, child tables the specifics.
Related
Assume that I have several realm objects (tables) with many connections between them, and I don't yet have all the objects pre populated.
I want to be able to create relationships by their ids (primary keys).
For example, I have JSON file with an object that has a list of another object's ids (not the actual object, although that another object is already exists in the realm db), I want to be able to populate those into objects directly without having to query them first.
How is that possible?
Realm is designed to be an object database without impedance mistach that could happen from mapping Java objects to an entry in table. Relation in Realm is specifically handled to adhere the principle above.
For example, one can describe relationship between object in following.
public class ObjectA extends RealmObject {
...
#PrimaryKey
private long id;
...
}
public class ObjectB extends RealmObject {
...
private RealmList<ObjectA> entries;
...
}
The relation you want, i.e. relation by primarykey id, seems much close to relational databases and it is not supported.
I am trying to configure a new database design seeing as we have decided to make the move to Hibernate. Previously in my Java code I had the following three classes
Super class
public abstract class Card {
private String firstname;
private String lastname;
private String email;
...
}
A card sub class
public class ContactCard extends Card{
private String variable1;
private String variable2;
private String variable3;
public ContactCard(){
super(firstname, lastname, email);
...
}
}
And a few others to follow. This seemed to work fine. However I am starting to get a little confused. Here we have the subclasses in is a relationships, some card is a card. I am failing to map this in to database tables though.
For example, to incorporate the process of a card table in the database I could have a table for each sub class type, and inside this table i could have an id which references a card table (which is generated when a user registers). But, this now means that in my database I have transformed the is a relationship in to has a? The subclass now has a card rather than is a card.
I am confused and hope someone can clear things up for me.
Thanks
The confusion stems from the fact that the ORM has to translate objects to relations and vice versa. is a is a relation that means a subclass in OOP terms, a class that extends the base class. However, in RDBMS terms you have relations (or tables, the two mean the same thing) and records/entities that belong to said relations.
Now, if you have a table that is mapped to your Card class, then the subclass (I will call it MyCard for now) cannot be inherited per se in your RDBMS, since there is no inheritance. So, instead of inheriting the record, some convention is needed in order to represent that concept instead.
If MyCard has a foreign key mapped to Card, then this means that there is a many-to-one relation (as long as Card does not have a foreign key as well, in which case there would be a one-to-one relation).
If I would have to create an is a relation in the table, then the first (but not best) idea I would come up with would be to have a foreign key both in the Card and the MyCard relation towards each-other, because this would technically force that the relation between the two tables is not being duplicated. However, what if you have a MyCard base relation and some other possible relations, like MyCard1, MyCard2, ... MyCard999 and your Card does not necessarily have matches to each of them, then your Card relation would be filled with 999 fields that rarely have values.
Even if there is a single MyCard relation, having a foreign key from Card to it is unnecessary, because, if we are consistently using it as an is a relation, then it will be an is a relation rather than a has a, even if there is no technical difference between the two representations.
As a result, it is better to only create a foreign key from MyCard to Card only, because then
your schema is as simple as possible
your schema is as easy to be maintained as possible
So, how can we represent this in OOP?
We can have a field in MyCard that represents the Card.
In short: this looks like an is a relation, but since it is consistently used as a has a relation, it is essentially a has a relation.
What's the use of #Embedded and #Embeddable In Hibernate ? Because every example i found on internet is inserting data inside of a single table and to do that using two different class. My point is if I am using a single table then I can map all the columns inside of a single class then why should i use different class. and if We use two different table then there is one-to-one and one-to-many hibernate relationship.
There are two types of objects in Hibernate
1. Value Object
2. Entities
Value Objects are the objects which can not stand alone. Take Address, for example. If you say address, people will ask whose address is this. So it can not stand alone.
Entity Objects are those who can stand alone like College and Student.
So in case of value objects preferred way is to Embed them into an entity object.
To answer why we are creating two different classes: first of all, it's a OOPS concept that you should have loose coupling and high cohesion among classes. That means you should create classes for specialized purpose only. For example, your Student class should only have the info related to Student.
Second point is that by creating different classes you promote re-usability.
When we define the value object for the entity class we use #Embeddable.
When we use value type object in entity class we use #Embedded
suppose we have employee table annotated with #entity and employee has Address so here i dont want to create two tables i.e employee and address, i just want create only one table i.e employee not Address table then we need to declare Address instance in Employee and add #embedable annotation on top of Address class, so finally we get table employee with its record and address records as well in single employee table
One entity can be embedded in another entity. The attributes of an entity can be common attributes of more than one entity. In this case there can be one embeddable entity. And this embeddable entity can be embedded in more than one entity.
Let's consider an example. We have one Animal entity, which has name and location attributes. Now two different entities Lion and Elephant can have Animal attributes just by embedding the Animal entity. We can override the attributes. In Animal entity there is location attribute and in Elephant there is place attribute. So with the help of #AttributeOverrides we can do like below:
#AttributeOverrides({ #AttributeOverride(name = "location", column = #Column(name = "place")) })
What is the difference between #Embedded annotation technique and #OneToOne annotation technique because in Embedded the java class contain "Has a" relationship in class and with the help of #Embedded annotation we persist the has a object in database. and in OneToOne relationship we also persist the has a object in database.
#OneToOne is for mapping two DB tables that are related with a one to one relationship. For example a Customer might always have one record in a Name table.
Alternatively if those name fields are on the Customer table (not in a separate table) then you might want an #embedded. On the face of it you could just add the name fields as standard attributes to the Customer entity but it can be useful if those same columns appear on multiple tables (for example you might have the name columns on a Supplier table).
Its the difference between composition and aggregation. #Embedded objects are always managed within the lifecycle of their parents. If the parent is updated or deleted, they are updated or deleted as well. #OneToOne objects may mimic composition via the cascadeType option of their #Join annotation, but by default they are aggregated, aka their lifecycle is separate from that of their parent objects.
#Embedded is used with Value Objects (Objects which have a meaning only when attached to an Object) whereas one to one mapping is between two objects having their own existence and meaning.
For e.g.
Value Object and #Embedded: If we have a User class and this class has an address Object in it, it can be considered as a value object as the address alone does not have any significance until unless associated with a user. Here address object can be annotated with #Embedded.
One to One mapping and #OneToOne: If we have a User class and this class has a 'Father' Object or a 'Mother' object, we would want to annotate the 'Father' or 'Mother' instance as #OneToOne as 'Father' or 'Mother' have their own meaning and existence and are not Value objects to User class.
A closely related difference is between #OneToMany and #ElementCollection. Both are used to save instance variables of Collection type in Java class. The difference being, #ElementCollection is to be used when the elements of Collection being saved are Value Objects whereas #OneToMany is used when the elments and object have well defined meaning and existence.
Use #OneToOne, only if fields can be reused. Otherwise, go for #Embeddable.
A quote from Beginning Hibernte, 3rd Edition:
There is nothing intrinsically wrong with mapping a one-to-one association between two entities where one is not
a component of (i.e., embedded into) the other. The relationship is often somewhat suspect, however. You should
give some thought to using the embedded technique described previously before using the #OneToOne annotation.
#Embeddable:
If the fields in an entity (X) are contained within the same table as another entity (Y), then entity X is called "component" in hibernate terms or "embedded" in JPA terms. In any case, JPA or hibernate do not allow to use 2nd table to store such embedded entities.
Generally, we think of normalizing a table when data is being reused by more than one table. Example: A Customer (id, name, street, city, pin, landmark) can be normalized into Customer(id, name) and CustomerAddress(cust_id, street, city, pin, landmark). In this case, we can reuse CustomerAddress by linking the same using cust_id with other tables. But if this reuse is not required in your application, then we can just keep all columns in one table.
So, a thumb rule is,
If reuse -> #OneToOne,
If no reuse -> #Embeddable
#Embedded is typically to represent a composite primary key as an embeddable class:
#Entity
public class Project {
#EmbeddedId ProjectId id;
:
}
#Embeddable
Class ProjectId {
int departmentId;
long projectId;
}
The primary key fields are defined in an embeddable class. The entity contains a single primary key field that is annotated with #EmbeddedId and contains an instance of that embeddable class. When using this form a separate ID class is not defined because the embeddable class itself can represent complete primary key values.
#OneToOne is for mapping two DB tables that are related with a one to one relationship. #Id will be the primary key.
I have banged my self with a very particular problem. Using OpenJPA (KODO 4.1) is there a way to use more than one column as a discriminator column?
My problem is that i have a table structure (which i have limited ability to modify of course) similar to this:
Table VEHICLE EXPENSIVE_CAR CHEAP_CAR EXPENSIVE_BOAT CHEAP_BOAT
---------------------------------------------------------------------------------
HORSE_POWER LUXURY_ACC CLASIFICATION SIZE SIZE
MEDIUM EXTRAS TV_SIZE
IS_EXPENSIVE CLASIFICATION
Where medium would discriminate between boat and car and is expensive would discriminate bettwen expensive or cheap.
So, is there any way to achieve this with the inheritance capabilities provided by OpenJPA (i know hibernate can use discriminator formulas but i am trying not to switch from the default JPA provider).
As a bonus if you can tell me about the custom discriminator strategies from OpenJPA that would be great since i have a hunch that it could be a plausible solution (even though i would prefer a vendor independent one)
Thanks a lot
Let's start backwards.
Discriminator strategies define the type of the column that discriminates related entities in the hierarchy. In JPA 1.x, it can be either a string (this is the default), a char and an integer.
Example:
import javax.persistence.DiscriminatorType;
import javax.persistence.DiscriminatorValue;
import javax.persistence.Entity;
#Entity
#DiscriminatorColumn(name = "TYPE", discriminatorType = DiscriminatorType.STRING, length = 5)
#DiscriminatorValue("FOO")
public class Foo { ... }
#Entity
#DiscriminatorValue("BAR")
public class Bar extends Foo { ... }
#Entity
#DiscriminatorValue("BAZ")
public class Baz extends Baz { ... }
If you are using is single table inheritance strategy as the default, this setup means that all these entities that are in the hierarchy will be mapped to the database table of the parent class, meaning you'll have a FOO table in your db with all the attributes of classes Foo, Bar and Baz plus a discriminator column called TYPE with the type of string (most likely some varchar-variant, length 5) and for each entity type, the respective discriminator value will be inserted automatically when persisted.
When you are finding Bar or Baz entities with JPQL, JPA will be able to find the entities from the FOO table (because that is the parent entity's table), and by relying on the contents of the discriminator column, your JPA provider will be able to discriminate between creating some Bar or Baz entities.
If you'd set the discriminator type to INTEGER or CHAR, then you could write for the values 1, 2, 3 or "A", "B", "C" etc. respectively.
Now to the OpenJPA question.
AFAIK there's no way to easily specify multiple discriminator values with OpenJPA, but you can create some more complex entity hierarchies, so if you'd be able to modify the schema, you could create a Vehicle entity, a Car, a Boat and both an ExpensiveBoat and an ExpensiveCar.
If you have to stick with your schema, I guess (but FIXME) you are using the joined or the table per class inheritance strategy which means you cannot use the discriminator feature that JPA provides.