JPA inheritance strategy including composition.

[Sergei Prosvirnin]

Hello, I hope to here advice regarding the most competent inheritance strategy in JPA.

I have many slightly different tables (Usefull class) for recording results of interactions with external service, plus I have classes like UsefullLog class (which is also very little different), where I directly save all information about HTTP interactions with other API. Plus I also have a nested enum class Statuses, which is also unique to the class Usefull.

My goal is to get a "common parent/interface" for lots of similar Usefull or UsefullLog classes, with each Usefull included.

I tried mistakenly starting by creating AbstractUsefull and AbstractUsefull with @MappedSuperclass but ran into the problem that it is impossible to include one @MappedSuperclass in another @MappedSuperclass. Plus in that case it's not clear to me how to be @AttributeOverride in UsefullLog.

Thanks, everyone will want to answer this question. I may not have described the problem correctly, and would be happy to get clarifying questions.

[Tim Holloway]

I think that the first thing we need to know is how many tables are involved.

If UsefullLog is a single table with multiple types of log entries - which is a common case - then you don't need/want @MappedSuperclass, because you can simply use a normal POJO superclass ("extends") with a discriminator to indicate which subclass the record belongs to.

@MappedSuperclass refers to an abstract table. You would use this if you wanted many different log tables instead of one log table with different record types.

[Sergei Prosvirnin]

Tim Holloway wrote:I think that the first thing we need to know is how many tables are involved.

If UsefullLog is a single table with multiple types of log entries - which is a common case - then you don't need/want @MappedSuperclass, because you can simply use a normal POJO superclass ("extends") with a discriminator to indicate which subclass the record belongs to.

@MappedSuperclass refers to an abstract table. You would use this if you wanted many different log tables instead of one log table with different record types.

I absolutely need multiple tables, one table per entity for logging. So I tried to start with @MappedSuperclass.

[Tim Holloway]

In that case, it would be useful to illustrate the class hierarchies you are looking for.

[Sergei Prosvirnin]

Tim Holloway wrote:In that case, it would be useful to illustrate the class hierarchies you are looking for.

I made an approximate UML showing the desired result for me, although there are definitely errors in this scheme (I should read something about UML, but so far I can only do this, sorry). And yes the nested unique enum I wish to see only in the logs.

[Tim Holloway]

OK, I think you have some arrows pointing in the wrong directions and maybe the wrong places.

Here's how I outlined your diagram. Classes marked (A) are abstract, classes marked C are concrete. Items marked E are @Entity:
UsefullParent (A)  UsefullLog (C, E)  UsefullParent1 (A)    UsefullLog1 (C, E)    UsefullParent2 (A)      UsefullLog2 (C, E)

I think what you probably want is table-per-class mapping: https://www.baeldung.com/hibernate-inheritance

[Frits Walraven]

A small note if you choose a table per concrete entity class: support of this feature is not guaranteed (spec JPA 2.1) and it has some serious drawbacks

2.12 Inheritance Mapping Strategies
Support for the table per concrete class inheritance mapping strategy is optional in this
release. Applications that use this mapping strategy will not be portable

[Tim Holloway]

"Serious drawbacks" include potentially serious overhead when doing queries on base classes (because a SQL UNION will be performed), and possible key collisions between tables. Actual software support should be safe for all versions of Hibernate JPA, but you might want to check if using some other JPA implementation such as Apache OpenJPA.

More practical would be a consolidated log table with variants (like Windows Event Manager/Linux journal log does)  or a joined core log data plus per-event-type tables. It is possible to get too fine-grained when designing databases and if that was a virtue, then NoSQL databases like MongoDB wouldn't be as popular as it is.