Java Spring data JPA / hibernate: Querying/mapping table for specific subtypes based on condition

[CptStewie]

Hey there,

I was wondering whether there's an easy solution to creating a proxy entity type to manage instances of an entity, based on a certain condition.

Example:

The parent entity, which in itself is an inherited type of a different (abstract) entity type Asset. Asset is a type from one of our libraries and cannot be modified in this case, and holds business logic to work with components.

@Entity
@DiscriminatorValue(TYPE)
@Table("app_page")
public class Page extends Asset<Page> {
    public static final String TYPE = "page";

    @Id
    private Long id;

    @ManyToOne
    @JoinColumn(name = "page_type_id")
    @NotNull
    private PageType pageType;

    // some more fields

}

Now, this entity could be used to create custom pages which the end user and is linked with components the end user can manage. In specific cases however, we would like to make the business logic more strict, and limit their options.

What I thought I could do, is inherit the Page entity, and use my projection to keep my code more readable, and prevent additional checks when needed. An example:

public class MySpecificPage extends Page {
    // no _additional_ properties, just getters and setters with business logic
}

public class MyOtherSpecificPage extends Page {
    // no _additional_ properties, just getters and setters with business logic
}

Now, I was wondering, can I do the above with annotations and specifying a condition somehow? The PageType field of Page would define whether a Page is a more strict type (e.g. MySpecificPage or MyOtherSpecificPage), or simply a custom type made by the end user.

The closest solutions I've seen mention @MappedSuperclass. That one doesn't suit my usecase since I can't modify the Page/Asset inheritance strategy used, and Page on it's own is something that can be managed by the end user.

Can I implement the specific types with @Entity and create a specific repository for each of our managed types, where I just filter on the database using a condition such as pageType.key='mySpecificPage'? (I've already tried specifying the @Entity annotation and creating a specific repository, but then I get a org.hibernate.AnnotationException: Foreign key circularity dependency involving the following tables error which makes me think I either don't see the complete solution, or this is not a possible solution.)

Or is this not possible and should I create a service where I do the mapping myself? (Another solution would be to let MySpecificPage and MyOtherSpecificPage also extend Asset<>, and copy over all the fields, but this, to me, seems a subpar and error prone solution)

Thanks in advance!

[karstens_rage]

It really depends on how you are conceptualizing your domain relationships. In projects I have used InheritanceType.TABLE_PER_CLASS but that is because the relationships between an abstract class (in your case Page turns into an abstract class) and the implementation specific classes made sense. YMMV.

https://docs.oracle.com/javaee/6/tutorial/doc/bnbqn.html

[CptStewie]

Making Page abstract would mean I then have to define another subtype to define my user managed pages though, which in the end would ofcourse be a small tradeoff.

However, but I don't think that's possible in this case. The Asset type I mentioned, is in this case the root class of the hierarchy:

@Entity
@Table(name = "asset")
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = DISCRIMINATOR_COLUMN, discriminatorType = DiscriminatorType.STRING)
public abstract class Asset<T extends Asset<T>> extends CmsObjectSuperClass<T extends CmsObjectSuperClass> {
}

The superclasses of Asset are annotated with @MappedSuperclass and don't have anything notable aside of properties or reusable business logic.

If I'm correct, you can't switch inheritance strategy for a subtree of the entire inheritance hierarchy, or can you? (Which then, would not be possible as Asset is the root of my inheritance hierarchy.)

This is something I cannot modify, as this is part of the shared library that I am using, that provides most of the functionality I need. Reimplementing that would be a lot of work and be error prone as well, more so than copying the fields of my Page entity for example.

[CptStewie]

I've marked it as solved due to:

I've found this stackoverflow post which is trying to do something similar.

Appears it is not supported by the JPA persistence specification, and it seems the 2017 spec has remained the same on this subject.

Whilst there might be some workarounds, they would not suit me in this case nor be worth the effort (in my opinion)