Spring Data r2dbc - Entity inheritance

Question

Spring data JPA with Hibernate supports annotiation javax.persistence.Inheritance and constants inside javax.persistence.InheritanceType . Based on these, inheritance between entity classes is mapped into DB (single table/joined table https://stackoverflow.com/a/3579462/12053054 ).

I was not able to find any similar mechanism to support entity inheritance with spring data r2dbc. I know that JPA and Hibernate stuff has nothing to do with r2dbc, but i don't see any problem with supporting inheritance in spring data r2dbc repositories nor any "anti-pattern" against functional programming.

Is there any workaround for this or any mechanism that would let me to use inheritance in spring data r2dbc repositories? (not just inheriting fields, but also translating inheritance to DB same as JPA/Hibernate does when calling spring data JPA repository methods). My only temporary workaround for this is to manually execute queries and implement spring data r2dbc repository methods on my own so i can translate inheritance into DB as well.

Answer 1

r2dbc is not an ORM (ie no OBJECT relational mapper) and hence the hole topic of object orientation is not supported. On a pure SQL basis there is no out-of-the-box inheritance, but you need to build your tables yourself that represent inheritance (but technically speaking they are just tables).

Classical approach: table mapping strategies

Until there is any ORM for r2dbc and the spring reactive stack you will need to implement the inheritance mapping to the tables yourself as well as the repositories that join the tables according to your mapping strategy. Most common strategies (with each having pros and cons) are:

• Single table (merge all columns into a single table)
• Concrete table (repeat all common columns per concrete table)
• Table per type (have a table holding common columns and then a table per concrete class with their added columns only)

Find more details on google or for example in this answer .

Alternative: schema-less

One other approach might be to use normal columns for the common attributes and a schema-less column for the data of subclasses. For example, when using postgres, it has very good support for the JSONB type that you could use to easily implement the repositories without a lot of joins etc.