I have an abstract entity A which has several union-subclasses. A.id generator was set to hilo (identity does not work). The other entity, B references this A entity as one-to-many (say, B.setOfA). Now if I try to persist an instance of B I get the following SQL error:
user lacks privilege or object not found: A
That's understandable since A doesn't generate any DDL during hbm2ddl. But I need to do exactly that -- polymorphic reference using abstract entity. How would I achieve that?
Related
I am trying to design a database schema so that it is applicable for the Hibernate's Table Per Class inheritance strategy. So, I will not let Hibernate to generate the tables, instead I need to design them myself in Liqibase but in such way that Hibernate can use them with that strategy.
My entity classes should look like this.
Vehicle.java
#Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public class Vehicle {
#Id #GeneratedValue
private int id;
private String name;
private String brand;
}
Car.java
#Entity
public class Car extends Vehicle {
private String oil;
}
Bike.java
#Entity
public class Bike extends Vehicle {
private String frame;
}
Now, I know that that this strategy means that all the fields are in all tables, but I am not sure about two things.
1) Do I need to include the ID in the derived tables?
2) Do I even need a Vehicle table in the DB, since it will actually never be used as an entity (rather just an abstract class)?
I'd appreciate if someone could clear that for me.
Now, I know that [the table-per-concrete-class] strategy means that all the fields are in
all tables,
Well no, you seem to be confused. With InheritanceType.TABLE_PER_CLASS, each concrete entity class E maps to a table that contains columns corresponding to all the fields of E, including inherited ones, but not including fields of entities that are not superclasses of E.
This is to be contrasted with InheritanceType.SINGLE_TABLE, in which all entity types in a whole inheritance hierarchy map to the same table, which then necessarily contains a column for each property of each entity in the hierarchy (without duplicating inherited fields).
Note also that it is odd that your Vehicle entity contains fields with the same names as fields of its subclasses. Java fields are not polymorphic, so this is unlikely to be what you want. It's certainly unnecessary.
but I am not sure about two things.
1) Do I need to include the ID in the derived tables?
Supposing that you stick with TABLE_PER_CLASS, yes, each entity table needs to provide a column for each persistent property of the corresponding entity class, including those inherited from superclasses. That includes id.
2) Do I even need a Vehicle table in the DB, since it will actually
never be used as an entity (rather just an abstract class)?
Not if you actually declare it abstract, but if you leave it concrete, then yes, you need a table for it. And that makes sense, because in that case you could have Vehicle entities that are neither Cars nor Bikes.
Hibernate schema generation tool should be able to generate your schema if you annotate your entities correctly.
In this case Vehicle table which be generated since your entity class is concrete. You need to define the class as abstract.
All the fields defined in the superclass (including the #Id) will be copied in the corresponding child class tables. There is a limitation though regarding id auto generation. You cannot use the table per class inheritance strategy with the GenerationType.IDENTITY strategy since the generated keys should be unique across all tables. Identity creates unique ids per table
Make sure the Generation.AUTO strategy does not map to the IDENTITY strategy for your RDBMS (You can specify a strategy explicitly eg GenerationType.TABLE to override the default)
I have the following mapping:
#Entity
#Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Vehicle {
#Id
#GeneratedValue
Long id;
}
#Entity
#Table(name = "car")
#AttributeOverride(name = "id", column = #Column(name = "car_id"))
public class Car extends Vehicle {
}
#Entity
#Table(name = "bus")
#AttributeOverride(name = "id", column = #Column(name = "bus_id"))
public class Bus extends Vehicle {
}
And what I'm trying to achieve is to query different tables for retrieving both Car and Bus entities. For this sake I've created the following Spring Data repository
public interface VehicleRepository extends CrudRepository<Vehicle, Long> {
}
and try to use it like this: vehicleRepository.findAll();
However, in this case I get java.sql.SQLSyntaxErrorException: ORA-00904: "KEY": invalid identifier. Seems like using #Inheritance together with #AttributeOverride for #Id field doesn't work.
What I'd like to point out is that if Car and Bus entities had the same mapping for #Id it would work perfectly (but it's not the case: "car_id" and "bus_id")
Also, I've tried to move #Id field from Vehicle class to subclasses, however it turned out that every #Entity should contain an #Id.
One more thing I'd like to mention is that I've tried using #MappedSuperclass instead of #Inheritance but in this case I'm not able to query with abstact Vehicle type.
Could anyone help me with that?
Thanks
You say,
And what I'm trying to achieve is to query different tables for retrieving both Car and Bus entities.
, but as a first consideration, you should evaluate whether you really want to do that. Think about this:
The single-table inheritance strategy is generally the fastest for whole-hierarchy queries such as you imagine performing. It can perform both whole-hierarchy and concrete-entity operations with single queries, without joins or unions.
The single-table and joined inheritance strategies ensure that all entities in the hierarchy have distinct keys, which is not necessarily the case for the table-per-class strategy.
The single-table and joined inheritance strategies facilitate relationships involving the abstract superclass; these are not well supported by the table-per-class strategy.
Support for the table-per-class strategy is optional. JPA providers are not required to support it, and the default provider in the GlassFish reference implementation in fact does not support it. Applications that rely on table-per-class therefore are not guaranteed to be portable. (Your provider, Hibernate, does support it.)
You go on to say,
However, in this case I get java.sql.SQLSyntaxErrorException:
ORA-00904: "KEY": invalid identifier. Seems like using #Inheritance
together with #AttributeOverride for #Id field doesn't work.
#AttributeOverride is only specified to work for overriding the attributes of mapped superclasses and fields and properties of embedded classes. It does work for #Id properties if they appear in those contexts. It is not specified to work (though neither is it specified to not work) for persistent fields and properties inherited from an entity superclass, but do observe that it cannot work for such properties with either the single-table or the joined inheritance strategy.
If #AttributeOverride did happen to work for you, that use would be non-portable. On the other hand, JPA has nothing else to accomplish what you want. A particular persistence provider could have an extension that supports it, but Hibernate has not historically done so -- all properties inherited from an entity superclass are mapped with the same names.
You also say,
One more thing I'd like to mention is that I've tried using
#MappedSuperclass instead of #Inheritance but in this case I'm not
able to query with abstact Vehicle type.
JPA does not provide a solution for your particular combination of requirements:
Mapping each concrete entity class to a separate table,
Naming the ID to a different column name in each entity table, and
Supporting polymorphic queries on the abstract supertype.
If you are unwilling to change any of those then you'll have to rely on an extension. And in that case you're in luck: Hibernate supports polymorphic queries where the polymorphic type is not mapped as an entity. Thus, if you're willing to make your application explicitly dependent on Hibernate, you can probably get where you want to be.
Specifically, to do this in Hibernate you would rely on "implicit polymorphism". To do this, you would avoid mapping the superclass as an entity, and from your experience, I guess it should not be a mapped superclass, either. It can be an ordinary class, though its properties would not be persistent, or you could use an interface instead. If your Vehicle class has properties that you want to make persistent, then you could change it to an embeddable class. You would furthermore annotate each of the vehicle entities to specify implicit polymorphism, for example:
#Entity
#Polymorphism(type = PolymorphismType.IMPLICIT)
// ...
public class Car implements Vehicle {
// ...
}
The Hibernate docs claim that implicit polymorphism is the default, but I recommend applying the #Polymorphism annotation anyway, for clarity.
I am using Play Framework 1.2.4 with PostgreSQL and JPA. I would like to have a Model hierarchy and see that there are some alternatives to doing this.
I have a base class (which is abstract) and two concrete classes extending this base class. I don't want to persist this base class while I want to have concrete classes. In the base class, I have another Model classes as properties, in other words, I have #ManyToOne relationships in my base class.
My question is what is the best way of implementing this? Using #MappedSuperclass or #Inheritance with TABLE_PER_CLASS strategy? I am a bit confused as they seem virtually equivalent.
I also have some concerns about querying and performance issues that I might face in future.
MappedSuperClass must be used to inherit properties, associations, and methods.
Entity inheritance must be used when you have an entity, and several sub-entities.
You can tell if you need one or the other by answering this questions: is there some other entity in the model which could have an association with the base class?
If yes, then the base class is in fact an entity, and you should use entity inheritance. If no, then the base class is in fact a class that contains attributes and methods that are common to several unrelated entities, and you should use a mapped superclass.
For example:
You can have several kinds of messages: SMS messages, email messages, or phone messages. And a person has a list of messages. You can also have a reminder linked to a message, regardless of the kind of message. In this case, Message is clearly an entity, and entity inheritance must be used.
All your domain objects could have a creation date, modification date and ID, and you could thus make them inherit from a base AbstractDomainObject class. But no entity will ever have an association to an AbstractDomainObject. It will always be an association to a more specific entity: Customer, Company, whatever. In this case, it makes sense to use a MappedSuperClass.
#MappedSupperclass is different than the #Inheritance annotation.
#MappedSuperclass tells the JPA provider to include the base class persistent properties as if they were declared by the child class extending the superclass annotated with #MappedSuperclass.
However, the inheritance is only visible in the OOP world, since, from a database perspective, there's no indication of the base class. Only the child class entity will have an associated mapped table.
The #Inheritance annotation is meant to materialize the OOP inheritance model in the database table structure. More, you can query a base class annotated with #Inheritance but you can't do that for a base class annotated with #MappedSuperclass.
Now, the reason why you'd want to use the #Inheritance JPA annotation is to implement behavior-driven patterns like the Strategy Pattern.
On the other hand, #MappedSuperclass is just a way to reuse both basic properties, associations, and even the entity #Id using a common base class. Nevertheless, you can achieve almost the same goal using an #Embeddable type. The only major difference is that you can't reuse an #Id definition with #Embeddable, but you can do it with #MappedSuperclass.
I have a entity hierarchy has single table for all subclasses strategy. And I want to use each properties - mapped #ManyToOne - as primarykey. When I put #Id annotation, I'm getting this error:
java.lang.ClassCastException: org.hibernate.mapping.SingleTableSubclass cannot be cast to org.hibernate.mapping.RootClass
So how can I provide to define all properties as identifier on discriminated hierarchy?
Your ID needs to be unique for the highest object in the hierarchy that is an entity. You can't define ID on subclasses and have an superclass, that is an entity, that has no ID.
Think of it this way, entityManager.find(SuperClass.class, 2); is a perfectly legal call. If ID were defined on subclasses as an FK column, more than one of them could have ID 2! What would be returned?
Using the FK side of a ManyToOne relationship as a primary key is nonsensical in the first place. It would by definition be a OneToOne then.
Where do i put my hibernate annotations?
Is it the line above my instance variable? Or before the getter? Or before the setter? Or doesn't it really matter?
Thanks a lot
You place them either on the field or on the getter. From the Hibernate Annotations Reference Guide:
2.2.1. Marking a POJO as persistent entity
(...)
Depending on whether you annotate
fields or methods, the access type
used by Hibernate will be field or
property. The EJB3 spec requires that
you declare annotations on the element
type that will be accessed, i.e. the
getter method if you use property
access, the field if you use field
access. Mixing annotations in both
fields and methods should be avoided.
Hibernate will guess the access type
from the position of #Id or
#EmbeddedId.
You might also want to read about the #Access annotation that allows to force/override the access type (prior to Hibernate Annotations 3.5 and JPA 2.0, it was part of Hibernate Annotation Extensions):
2.2.2.2. Access type
By default the access type of a class
hierarchy is defined by the position
of the #Id or #EmbeddedId annotations.
If these annotations are on a field,
then only fields are considered for
persistence and the state is accessed
via the field. If there annotations
are on a getter, then only the getters
are considered for persistence and the
state is accessed via the
getter/setter. That works well in
practice and is the recommended
approach.
Note
The placement of annotations within a class hierarchy has to be consistent
(either field or on property) to be
able to determine the default access
type. It is recommended to stick to
one single annotation placement
strategy throughout your whole
application.
However in some situations, you need
to:
force the access type of the entity hierarchy
override the access type of a specific entity in the class hierarchy
override the access type of an embeddable type
The best use case is an embeddable
class used by several entities that
might not use the same access type. In
this case it is better to force the
access type at the embeddable class
level.
(...)
Regarding the pros and cons of both styles, I suggest to read the following questions:
Hibernate/JPA - annotating bean methods vs fields
Hibernate Annotations - Which is better, field or property access?
Performance difference between annotating fields or getter methods in Hibernate / JPA
It's up to your style. You may put it before the field or before getter. In strict JPA, the annotations on setters are ignored, but I'm not sure if Hibernate follows that.
You either need to be consistent throughout your Entity, or you need to provide an #Access annotation at the top of the class with a default mode, and another #Access before each field/property you wish to deviate from the current class mode.
Hibernate is known to use Java reflection. So it really doesn't matter whether you put it above the filed or above the getter.
Here is the description of some important annotation used in Hibernate.
#Entity: declares the class as an entity (i.e. a persistent POJO class)
#Table: is set at the class level; it allows you to define the table, catalog, and schema names for your entity mapping. If no #Table is defined the default values are used: the unqualified class name of the entity.
#Id: declares the identifier property of this entity.
#Generated Value: annotation is used to specify the primary key generation strategy to use. If the strategy is not specified by default AUTO will be used.
#Column: annotation is used to specify the details of the column to which a field or property will be mapped. If the #Column annotation is not specified by default the property name will be used as the column name.
Annotations based Inheritance mapping in Hibernate:
There are three kinds os inheritance mappings in hibernate.
They are
1.Table per Class hierarchy:
#Inheritance – Defines the inheritance strategy to be used for an entity class hierarchy. It is specified on the entity class that is the root of the entity class hierarchy.
#DiscriminatorColumn – Is used to define the discriminator column for the SINGLE_TABLE inheritance mapping strategies. The strategy and the discriminator column are only specified in the root of an entity class hierarchy or sub hierarchy in which a different inheritance strategy is applied
If the #DiscriminatorColumn annotation is missing, and a discriminator column is required, the name of the discriminator column defaults to "DTYPE" and the discriminator type to DiscriminatorType.STRING.
#DiscriminatorValue – Is used to specify the value of the discriminator column for entities of the given type. The DiscriminatorValue annotation can only be specified on a concrete entity class. If the DiscriminatorValue annotation is not specified and a discriminator column is used, a provider-specific function will be used to generate a value representing the entity type. If the DiscriminatorType is STRING, the discriminator value default is the entity name.
2.Table per sub Class hierarchy:
#InheritanceType – Defines inheritance strategy options. JOINED is a strategy in which fields that are specific to a subclass are mapped to a separate table than the fields that are common to the parent class, and a join is performed to instantiate the subclass.
#PrimaryKeyJoinColumn – This annotation specifies a primary key column that is used as a foreign key to join to another table.
3.Table per Concrete class hierarchy:
#InheritanceType – Defines inheritance strategy options. TABLE_PER_CLASS is a strategy to map table per concrete class.
#AttributeOverrides – This annotation is used to override mappings of multiple properties or fields.
#AttributeOverride – The AttributeOverride annotation is used to override the mapping of a Basic (whether explicit or default) property or field or Id property or field.
Hope it help's to get idea on basic annotation used in hibenate.