如何从 Spring 数据 JPA 中的 id 解析不同的实体？

Question

Some Background to my application:
I'm developing a Discord-Bot in Java using Spring Boot, Spring Boot Data JPA and JDA.
The bot is supposed to have several buttons in Discord with different purposes. When a user clicks a button, the bot gets the id (which I gave it beforehand when I created it) of the button in an event-handler.

Different example scenarios:

1. Button1 with the id 20 resolves to a role-button-entity with Role1, so the Member gets Role1 assigned.
2. Button2 with the id 32 resolves to a ticket-button-entity with some logic that runs on click.

(The different button entities also have different fields)

Question: How can I design something like this?

One option that came to my mind is to have a generic-button-entity, so that JPA's id represents the id from the button in Discord and it stores another id (eg,from a role-button-entity, to run its logic with its fields instead of the ticket-button-entitiy's logic/fields).
Does this option make any sense and if so, is it possible to cascade the Long buttonEntityId with eg the role-button-entity?

Thanks in advance

Answer 1

There are some dessign patterns that would fit in your business case. A Factory for instance to decide which button type to create, or a Strategy to decide which behaviour to perform.

But either way, every one needs to take a path or another based on some parameter/attribute/property. You are saying that you want to use the ID of the element to do so, that is the same ID that would be used as the PRIMARY KEY in the ddbb. So meaning two different independent tables, but with a shared uniquenes in the ID ...

That, as almost everything in software, can be achieved, but it's a clear code smell, a design smell. Using some id as a discriminator, not for the id value itself, but for the data it represents... Doesn't make sense.

You can manage to do it, but the solutions you're gonna use, the workarrounds you'll have to perform, and the pitfalls that all that would imply will definitely make your code less readable, maintainable and scalable.

A path that would make much more sense is a specific property bound to the buttons that specify the type it is, and use this in the patterns/logic to do/create either one think or another. Efforts towards this solution will give you much better results.

Regarding the database representation of this solution, unless you find a reason why, you don't even need to have a TYPE column, as that can be directly inferred from the TABLE/entity, meaning that it can directly be a constant in the entity.