Best practice to manage CRUD of @OneToMany

[Marcusbiel]

Please help me to the light, I don’t see it yet so simple ;).

So first of all I have these complex filters that I would all need to refactor:

Complex Filter with Criteria API

I use Java 20 with Quarkus 3.0.2 and Hibernate 6.2. I have customers, each customer can have their own customers, “end_customers”. A customer usually has 1000-300k customers, I would say 3000-5000 on average. Each customer can define a series of self-defined, custom fields. Each field has a field type, like text, number, date, or a constrained text value. The data is stored in a mariadb database. Here’s the current SQL DDL: CREATE TABLE end_customer ( id varchar(36) NOT NULL, external_id …

Then I’d need to adjust the entities, the database tables, migrate staging and PROD, and find a way to ensure referential integrity in a performant / good to maintain way, as well as update the logic to allow adding / updating / deleting fields and labels, adjust my integration tests.

My estimate would be 1-2 weeks part-time for all that.

Besides, here’s the reason why I’d want to move the logic out of the entity:

1. Class is generally too long. Extracting it would allow me to better break it down.
   I coculd try to mitigate that by calling some static helper classes / methods from the entity instead.

2. My original attempt was not to use any hibernate /JPA related (annotation based) logic,
   and just have the 2 service classes manually calling another service that they have autowired, when a field is changed. The advantage would be - less magic - and less depending on Hibernate. As a result, easier to understand, test, and maintain.

But I guess in the best case I could just see that there is an attempt to change a field, I would, without annotations not see if the value was truly changed, and I would not have a way to react AFTER the transaction is committed - because it may happen that I’d inform about the field changes, when a rollback happens, that would at a minimum cause the trigger to be executed twice.

So it seems I have to use some Hibernate/JPA Annotation based “magic” solution anyway… and that removes a bit of the argument of removing the logic from inside the parent entity and just keeps the need to make it simpler. Maybe I should instead create a static Factory that would calculate the new state which then could be applied to the child entities in a simpler way.

Regarding Hibernate Interceptors, GPT-4 tells me, in order to be informed of any changes AFTER the commit, I would have to use the `PostCommitUpdateEventListener, which is part of the Hibernate SPI and therefore might not be stable.

Woah sorry I am a bit lost atm

Thanks for your time . Grateful.