We Keep Coding

JPA Table per Class Inheritance with different Id names

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.

What are the default JPA annotations

I am working on a project that uses JPA and hibernate, and I've just noticed that the entities don't have any relationship annotations such as #ManyToOne, #OneToOne, etc.
So my question is, does JPA/Hibernate adds a default annotation for each case?
Here is an examples
#Entity
#Table(name = "strategy")
public class Strategy extends TradingEntity implements Serializable {
...
#Valid
private List<Rule> rules;
Does JPA add a #OneToMany annotation by default to this property ?

There are no "default" annotations, but some JPA implementations (e.g the one I've been using, DataNucleus) are intelligent enough to work out that if a field is a Collection of an Entity type then it is a OneToMany/ManyToMany and to default things like fetching and cascading etc. Clearly you cannot assume that your implementation will have this logic so should put what you need (and "JPA" does nothing, it is your implementation that would do it). Clearly also, you can specify the same info in XML so could have no annotations

Implementing Entity

I am marking some of JPA class with predefined interface say Auditable. Now I want to invoke EntityListeners Auditor #PrePersist marked method. This has to be done to only those entity which implements this interface. I can see we can do this on Parent Classes but are interface allowed ?

Using interface is wrong here it is you must use abstract class ,interface is just used to represent class behavior not persistent field. by the way try see eclipse link they support additional thing in interface.
http://en.wikibooks.org/wiki/Java_Persistence/Advanced_Topics#Interfaces

JPA: Implementing Model Hierarchy - #MappedSuperclass vs. #Inheritance

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.

Best way to share Java implementation between concrete JPA classes?

I have about 10 different entities in my J2EE application that right now share the exact same implementation. They all inherit from the same generic abstract class that has been annotated as a #MappedSuperclass, but this class contains none of the implementation I have repeated in all the concrete subclasses.
If I could, I'd put all the various fields and collections on this abstract superclass and therefore put the implementation methods there too -- all in one place instead of 10. However, due to JPA restrictions I cannot add JPA annotations to generic fields or accessors.
While I normally favor delegation to implementation inheritance anyway, due to another JPA restriction that says you can't have an embedded entity with a collection the idea of using a delegate also won't work.
When I had only 3-4 of these entities and 2-3 methods, it wasn't a big deal, but now I have about 10 -- and about 7-8 methods each...and some of the methods are getting really complex. And the "cut-copy-paste" inheritance I am using really sucks.
Any other brilliant ideas out there?

Double-check whether these "restrictions" actually hold true for your JPA provider. I've had embedded objects with collections and it has been fine (with Hibernate). And I've had a #MappedSuperclass with mapped fields.
You can try omitting the #MappedSuperclass, and make the superclass abstract and an #Entity with the proper inheritance hierarchy.

It turns out you can use either implementation inheritance or delegation as long as you are sure to use property access mode for your JPA annotations. I was using field access mode for JPA annotations and that was causing me no end of suffering because I could not annotate a generic field type.
However with property access mode I simply create my generic abstract implementation without annotating it as an entity, mappedsuperclass, embeddable, or anything. This way JPA will ignore it. Then, in the concrete subclasses, I create protected getter and setters methods as needed and put the JPA annotation on those.
Turned out to be deceptively simple.