Deprecation of EntityPersister#update in Hibernate 6.5

Hibernate ORM
1

Currently, we use the 6.2.31 Hibernate version and we are going to upgrade to 6.6 version.
We extend the AbstractEntityPersister class in our project to apply some custom logic.

In our current Hibernate 6.2 version, these custom EntityPersisters are called from

org.hibernate.action.internal.EntityUpdateAction#execute

method.

But in 6.6 version the method call

persister.update(…)

was replace to

persister.getUpdateCoordinator().update()

After these changes our Custom EntityPersisters became dysfunctional.

  1. I have not found any documentation or migration guides from deprecated

org.hibernate.persister.entity.EntityPersister#update

to

UpdateCoordinator#update

except for a short description of the deprecated method
Are there some migration guides, or examples of how to use UpdateCoordinator?

  1. Some methods of AbstractEntityPersister became deprecated.
    For example,

EntityPersister#update, EntityPersister#insert.

But some still is in use, e.g.:

AbstractEntityPersister#load

Does this mean that we need to migrate

EntityPersister#update > UpdateCoordinator#update

and

EntityPersister#insert> InsertCoordinator#insert

But

AbstractEntityPersister#load

can we use it as before?

2

AbstractEntityPersister is an internal implementation detail as you can see when looking at the class declaration through the @Internal annotation, so changes done to that class are not documented in a migration guide.
EntityPersister is an interface that we aim to keep backwards compatible for usage, but if you want to implement it yourself, you have to research the changes and understand how Hibernate ORM uses things.

We introduced the UpdateCoordinator and InsertCoordinator to allow retrieving generated values in a more efficient manner i.e. make use of the returning clause that many SQL dialects offer. Previously, generated values were always fetched after emitting an update through separate operations.

You can figure out these things by using git blame to understand which commits introduced a change, which usually points to a HHH- issue key where you can find further information.

Maybe you can share your use cases that require you to extend these classes in the first place? Ideally, you wouldn’t have to do that and hence also be spared of the upgrade trouble that you’re in right now.

3

@beikov
Thank you for your quick response.
The main part of this functionality looks like this:
In our application, we have 2 types of DB objects:
“clone” and “original” entities.
When we persist an object we iterate through the linked entities of the current object and change the IDs of these linked objects from “clone” to “original”.

Currently, we do it in the extended class (all below code is simplified):

public class CustomJoinedSubclassEntityPersister extends JoinedSubclassEntityPersister {

public UpdateHandler updateHandler = new UpdateHandler();

@Override
public void update(some fields ..) throws HibernateException {
    if (updateHandler.processUpdate(some fields ..)) {
        super.update(some fields ..);
    }
}

}

And I going to implement in 6.6 something like this.
Does the below implementation of UpdateCoordinatorStandard make sense?
If yes then how can we activate this extended UpdateCoordinator?

public class CustomUpdateCoordinator extends UpdateCoordinatorStandard {

@Override
public GeneratedValues update(some fields ...) {
    UpdateHandler entityPersister = this.entityPersister();
    if (entityPersister instanceof CustomJoinedSubclassEntityPersister) {
        UpdateHandler updateHandler = entityPersister.getUpdateHandler();
        if (updateHandler.processUpdate(some fields ...)) {
            return super.update(some fields ...);
        }
    }
}

}

4

No idea why you’re doing that, but your implementation in principle looks ok to me. You can activate this by returning an instance of that type from EntityPersister#getUpdateCoordinator

1 Like
5

@beikov
Thanks for your help!